From: walt
> > In the meantime, try this patch, which is something of a long shot.
>
> No difference. But I notice the code enables the TRB quirk only if the
> xhci_version is specifically 0x95. My debug messages claim that "xHCI
> doesn't need link TRB QUIRK" so I'm wondering if adding my asmed
From: gre...@linuxfoundation.org
> > ...
> > > +#ifdef
> > > +static inline void imx28_ci_writel(u32 val, volatile void __iomem *addr)
> > > +{
> > > + __asm__ ("swp %0, %0, [%1]" : : "r"(val), "r"(addr));
> > > +}
> > > +#else
> > > +static inline void imx28_ci_writel(u32 val, volatile void __iom
From: Bjørn Mork
> Thomas Kear writes:
>
> > On Sat, Jan 11, 2014 at 11:09 AM, Bjrn Mork wrote:
> >> But looking at the code I think I found and obvious miss in the SG list
> >> initialisation. I'll post a proposed fix for that. Would be good if
> >> someone was able to test it.
> >
> > I've b
From: Bjørn Mork
> David Laight writes:
>
> > The patch you submitted is wrong.
> > Whoever wrote the sg interface was on crack.
> > The 'last' marker needs moving as well.
>
> I'm afraid I don't understand what you meant by this.
>
> s
From: Bjørn Mork [mailto:bj...@mork.no]
> David Laight writes:
> > From: Bjørn Mork
> >> David Laight writes:
> >>
> >> > The patch you submitted is wrong.
> >> > Whoever wrote the sg interface was on crack.
> >> > The 'last&#
From: Mathias Nyman
> This is an attempt to re-work and solve the issues in xhci command
> queue management that Sarah has descibed earlier:
>
> Right now, the command management in the xHCI driver is rather ad-hock.
> Different parts of the driver all submit commands, including interrupt
> handli
From: walt
> On 01/09/2014 03:50 PM, Sarah Sharp wrote:
>
> >>> On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote:
> >>
> >> I've wondered if my xhci problems might be caused by hardware quirks, and
> >> wondering why I seem to be the only one who has this problem.
> >>
> >> Maybe I could "take
From: Mathias Nyman
...
> > The fact that you are having to allocate memory ion an ISR ought also to be
> > ringing alarm bells.
>
> It did.
> Other options are as you said to use a 'software command ring'. Either
> just pre-allocate a full command ring (64 trbs * sizeof(struct
> xhci_command)),
From: Sascha Weaver
> Sent: 15 January 2014 06:49
> To: linux-usb@vger.kernel.org
> Subject: xhci-hcd (millions of) "Too many fragments" error on LUKS-encrypted
> device
>
> Hi there,
>
> this bug was reported to Arch Linux community but they say I need to
> take this upstream: https://bugs.arch
From: Arnaud Ebalard
> Sent: 14 January 2014 21:54
> To: Sarah Sharp
> Cc: linux-usb@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Bjørn
> Mork
> Subject: Re: [BUG] FL1009: xHCI host not responding to stop endpoint command.
>
> Hi Sarah,
>
> Sarah Sharp writes:
>
> >> I can add the fo
From: tatxarata
> Update on my current research status.
>
> 1. To get normal read/write speed over USB3 I have to set max_sector_kb
> to 64. Otherwise write is fine, but read is very slow (about 300kb/s).
> Maybe this is hardware issue of this reader/card. However over USB2 all
> works fine withou
From: Sascha
> 2014/1/15 David Laight :
> > This is a known problem.
> > A side effect of trying to fix USB ethernet.
> >
> > There is a patch lurking to increase the ring size from 64 to 256.
>
> Thanks, but where could I get the patch? I searched a bit bu
I have a theory, I'll try to write a non-invasive patch.
In spite of the comments and some code paths inc_enq() is only
called by (and has only ever been called by) queue_trb(), so
is only called for transfer and command rings.
It takes care to avoid advancing past the LINK TRB.
The coding would
From: Alan Stern
> On Wed, 15 Jan 2014, David Laight wrote:
>
> > I have a theory, I'll try to write a non-invasive patch.
> >
> > In spite of the comments and some code paths inc_enq() is only
> > called by (and has only ever been called by) queue_trb(), so
From: David Laight
> From: Alan Stern
> > On Wed, 15 Jan 2014, David Laight wrote:
> >
> > > I have a theory, I'll try to write a non-invasive patch.
...
> >
> > Doesn't this mean you shouldn't change the ownership of a LINK TRB
> > unt
From: David Laight
> From: David Laight
> > From: Alan Stern
> > > On Wed, 15 Jan 2014, David Laight wrote:
> > >
> > > > I have a theory, I'll try to write a non-invasive patch.
> ...
> > >
> > > Doesn't this mean you shouldn
From: Sarah Sharp
> > >- xhci_warn(xhci, "WARN Set TR Deq Ptr cmd failed because
> > >"
> > >- "slot %u was not enabled.\n", slot_id);
> > >+ xhci_warn(xhci, "WARN Set TR Deq Ptr cmd failed because
> > >slot "
> > >+
>last_trb is set using a static inline function since a minor
implementation change might require a different scheme.
I've also taken the liberty of on tracing short receives when they
are unexpected. Otherwise every ethernet receive generates a trace
(when the xhci_debug() trace is enabled
From: Sascha Weaver [mailto:wzy...@wzyboy.org]
...
> The patches, they both do their jobs: the first does not fix the bug
> but "Too many fragments" error messages are limited to just one line.
> The second patch does fix the bug, great. I can see it changes two
> more lines in xhci.c. What's its a
From: walt
> Oy, Sarah! ;) I put the ASMedia adapter in my older amd64 machine, and, well,
> the stupid thing Just Works(TM) with kernel 3.12.7! (Yes, with the same disk
> docking station, too.)
>
> I can't believe the adapter works perfectly in a different computer. Have you
> seen this kind o
From: Ming Lei
> On Mon, Jan 13, 2014 at 9:26 PM, David Laight wrote:
> >>
> >> I believe all processing use the urb->num_sgs field to limit the number
> >> of entries. Common interfaces like dma_map_sg() and for_each_sg() limit
> >> their processing to
erved slot.
If 'command_must_succeed' is set, only check that a single entry is
available.
Note that entries are not dynamically reserved and then consumed later.
Initially one entry is reserved, later another is reserved for each active
stream.
Signed-off-by: David Laight
---
drivers/usb/host/xhci-rin
From:
> On 01/17/2014 06:34 AM, David Laight wrote:
>
> > Can you try the patch I posted that stops the ownership on LINK TRBs
> > being changed before that on the linked-to TRB?
>
> Sadly, the patch didn't fix the ASMedia lockup behavior, however :(
>
> I
From: Sarah Sharp
> This is fixed in the revised patch, David. Please read through the
> entire thread before commenting, thanks.
Sorry, I should have noticed that you said that you'd applied the
'checkpatch' fixes.
I'm more or less forced to read these lists with outlook, it makes
looking at th
From: walt
> On 01/17/2014 06:34 AM, David Laight wrote:
>
> > Can you try the patch I posted that stops the ownership on LINK TRBs
> > being changed before that on the linked-to TRB?
>
> Please disregard my earlier post about the patch not applying cleanly.
> That wa
values in the 64bit one,
and use it is the one place where immediate data is passed.
Signed-off-by: David Laight
---
Patch is against 3.13.0-rc8
drivers/usb/host/xhci-dbg.c | 8 +-
drivers/usb/host/xhci-ring.c | 166 ++
drivers/usb/host/xhci-tra
From: Sarah Sharp
> On Mon, Jan 20, 2014 at 11:21:14AM +0000, David Laight wrote:
...
> > A guess...
> >
> > In queue_bulk_sg_tx() try calling xhci_v1_0_td_remainder() instead
> > of xhci_td_remainder().
>
> Why? Walt has a 0.96 xHCI host controller, and the for
From: Sarah Sharp [
> On Thu, Jan 16, 2014 at 10:21:11AM +0000, David Laight wrote:
> > From: David Laight
> > > From: David Laight
...
> > > Below is a possible patch, I've only compile tested it.
> > > I've minimalised the patch by not removing
Don't trace short receives if URB_SHORT_NOT_OK is set.
Short receives are normal for USB ethernet devices.
Don't trace unexpected incomplete receives if XHCI_TRUST_TX_LENGTH is set.
Ratelimit the trace.
Signed-off-by: David Laight
---
If these two traces ever happen, then they will
queue_trb().
The code never generates LINK TRB pointing to LINK TRB - so the loops
in the old code are not needed. Similarly inc_enq() has never been
called for event rings - so those checks aren't needed.
Signed-off-by: David Laight
---
drivers/usb/host/xhci-ring.c | 211
ll,
but that opened another bag of worms.
David Laight (5):
xhci: Don't change the ownership of LINK TRB until all the TRB are
written
xhci: isoc transfers can't fail when partially queued - remove cleanup
code.
xhci: Pass the 'ep_ring' to prepare_transfer().
xhc
ning_total' check is just checking that the code is correct
and can just be deleted now the code is working.
Remove the 'flip_cycle' parameter to td_to_noop() since it is no longer
ever set.
Signed-off-by: David Laight
---
drivers/usb/host/xhci-ring.c | 56 ---
prepare_transfer() looks up the endpoint ring structure, however
the caller already knows it.
Save code and an error test that can never fail by passing the ring
address instead of the stream_id.
Signed-off-by: David Laight
---
drivers/usb/host/xhci-ring.c | 18 +-
1 file
giveback_first_trb.
There are no references left to ring->cycle_state or TRB_CYCLE
(or 0x1 meaing TRB_CYCLE) in the code that generates TRB.
Signed-off-by: David Laight
---
drivers/usb/host/xhci-ring.c | 78 +++-
1 file changed, 5 insertions(+),
TRB) on all
the queue_trb() calls except the very last one.
Signed-off-by: David Laight
---
Note that this differs to any previous similar patches I've sent
because it contains a fix to the isoc code.
However I've only tsted it with USB3 ethernet.
drivers/usb/host/xhci-ring.c | 84 ++
From: walt
> On 01/21/2014 01:51 AM, David Laight wrote:
> > From: Sarah Sharp
> >> On Mon, Jan 20, 2014 at 11:21:14AM +, David Laight wrote:
> > ...
> >>> A guess...
> >>>
> >>> In queue_bulk_sg_tx() try calling xhci_v1_0_td_remai
From: Sarah Sharp
> On Tue, Jan 21, 2014 at 12:02:56PM +0000, David Laight wrote:
> > Don't trace short receives if URB_SHORT_NOT_OK is set.
> > Short receives are normal for USB ethernet devices.
> >
> > Don't trace unexpected incomplete receives if XHCI_TRUS
From: Jay S
> [2.] I have a 1 TB Western Digital drive in a USB 3.0 HDD dock that will
> not automount while XHCI is enabled in the BIOS. If I disable XHCI in
> the BIOS, it automounts normally. I've tried an external USB 3.0
> enclosure and two different brands of USB 3.0 HDD docks (that use
> dif
From: Sarah Sharp
...
> If it really matters that a driver be able to get an immediate -EPIPE
> response back from a device when the endpoint is halted, I can rip the
> code out of xhci_endpoint_reset() and make the driver manually clean up
> the ring at the time of the stall, like it does for cont
From: Stanislaw Wadas
> Replace hard coded value of 256 by two constant
> defines, MAX_LENGTH and MAX_PATH_LENGTH
Neither of those names is really very good.
They probably ought to be prefixed with USBG_
Mind you the rest of the file isn't much better.
There are also some 'char name[40];'
And co
From: Sarah> Sharp
> On Wed, Dec 18, 2013 at 11:24:47AM -, David Laight wrote:
> > This saves a kzalloc() call on every transfer and some memory
> > indirections.
> >
...
> Hi David,
>
> The patch looks good in general and applies fine. However, in testi
From: Stanislaw Wadas
> Add error handling to fputs()/fgets() functions.
...
> - fputs(buf, fp);
> + if (fputs(buf, fp) == EOF) {
> + ERROR("write error");
> + fclose(fp);
> + return;
> + }
Pointless...
Most code that looks at the return value of fpu
From: Of Stanislaw Wadas
> Add inline to gadget_write_string().
...
> -static void usbg_write_string(char *path, char *name, char *file, char *buf)
> +static inline void usbg_write_string(char *path, char *name, char *file,
> char *buf)
> {
> usbg_write_buf(path, name, file, buf);
> }
Why
From: Jérôme Carretero
> Hi Sarah,
>
> I was happily using big (10MB) buffers before, and with recent kernels,
> when using USB3, I had to reduce the size of my buffers a lot.
> By the way, I couldn't find any information on a maximum size for the
> bulk transfers using libusb, maybe you know abou
From: Sarah Sharp
> Hi David,
>
> I've been thinking about this some more, and I'd like to propose a much
> simpler solution.
>
> The TD fragment rules didn't go into the xHCI specification until the
> 1.0 revision. The code that follows those rules only seems to trigger
> issues for 0.96 ASMedi
d-off-by: David Laight
---
Note that this patch just allows large numbers of aligned fragments for
bulk scatter-gather transfers.
It doesn't remove the need for the patch that changes the way the ownership
of the the first TRB is set in order to avoid the controller seeing 'dangling'
L
If you cancel an isoc urb that has multiple TD (I suspect this
is most isoc urb) then (if I'm reading the code correctly) the urb
completion routine is called for each TD, and the memory for each
td_list entry is freed separately (even though they are allocated
by a single kmalloc()).
Neither of th
From: David Laight
> Transfer requests for usb disks can contain a large number of 4k fragments.
> Assume that it doesn't matter if there are LINK TRB in fragment lists
> that are 1k aligned.
>
> This should stop errors when transfer requests for usb disks contain
> more
Many of the net/usb ethernet drivers (including common ones like
the smsc95xx) will fail to transmit all packet length properly
when connected to a USB3 port (ie using the xhci driver).
The underlying problem is that they assume the host controller
will honour the URB_ZERO_PACKET flag - which usbn
From: Jérôme Carretero
> I was happily using big (10MB) buffers before, and with recent kernels,
> when using USB3, I had to reduce the size of my buffers a lot.
> By the way, I couldn't find any information on a maximum size for the
> bulk transfers using libusb, maybe you know about that also ?
>
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 a
From: Michal Nazarewicz
> On Tue, Jan 28 2014, David Laight wrote:
> > 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
From: Of Bjørn Mork
> Rafal Milecki writes:
>
> > Hi,
> >
> > This is report from my Samsung NP700G7A-S01PL. This notebook has two
> > USB 2.0 ports and two 3.0 ports.
> >
> > Starting with the following commit:
> >
> > commit 7dd09a1af2c7150269350aaa567a11b06e831003
> > Author: Xenia Ragiadakou
From: Xenia Ragiadakou
> On 29/01/2014 12:08 μμ, Rafał Miłecki wrote:
> > 2014-01-29 David Laight :
> >>> Maybe I misunderstand something, but won't that commit end up replacing
> >>> the previous pair of writel() with a single native writeq() on 64bit
>
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
From: Michal Nazarewicz
> On Wed, Jan 29 2014, Robert Baldyga wrote:
> > + /* open endpoint files */
>
> ep_path = malloc(strlen(argv[1]) + 4 /* "/ep#" */ + 1 /* '\0' */);
> if (!ep_path) {
> perror("malloc");
> return 1;
> }
>
> At this point you
sted on an Intel v1.00 controller with the ax88179_178a and smsc95xx
ethernet controller (the former patched so that it needs the ZLP).
Verifying with extra traces that the ZLP are sent for ping -s $((1024-0x32))
(and 512-0x32 for the smsc95xx - which has the same red tape length).
David Laight (
x27; and to check for the
last fragment (instead of num_trbs - which is now only used for
the call to prepare_transfer().
- No need to pass 'more_trbs_coming' to queue_trb(), it is implied
if TRB_CHAIN is set.
- Finish the loop when we failed to set TRB_CHAIN.
Sign
we can only add LINK TRB at aligned offsets)
If the upper bound won't fit in the current segment, then calculate
the actual number or fragments (more efficiently than before).
Ignore zero-length non-terminal fragments.
Signed-off-by: David Laight
---
drivers/usb/host/xhci-ring.c
The TRB type and flags are the same for all the TRB expect the first
(which needs the opposite value of TRB_CYCLE) and the last (which
needs TRB_CHAIN clear and TRB_IOC set).
So move the code that sets it up outside the loop.
Signed-off-by: David Laight
---
drivers/usb/host/xhci-ring.c | 48
The calculation done for the first fragment is exactly the same
as the one for subsequent fragments.
So move both versions to inside the loop at the top.
Simplify the calculation for the distance to the next 64k boundary.
Remove the never-checked 'num_sgs'.
Signed-off-by: Da
The check_trb_math() function and the check for sg buffers crossing 64k
boundaries are checks that the local function is correct.
Since the code is correct they can be removed.
Signed-off-by: David Laight
---
drivers/usb/host/xhci-ring.c | 26 --
1 file changed, 26
d-off-by: David Laight
---
drivers/usb/host/xhci-ring.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index afd8eeb..1324bb0 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb
the value can be calculated much more
easily.
Signed-off-by: David Laight
---
drivers/usb/host/xhci-ring.c | 34 ++
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index bf9a20f..afd8eeb
Modify the code in queue_bulk_sg_tx() to support non-sg transfers.
Rename it xhci_queue_bulk_tx() and delete the old xhci_queue_bulk_tx().
Signed-off-by: David Laight
---
drivers/usb/host/xhci-ring.c | 159 ---
1 file changed, 15 insertions(+), 144
The number of trbs depends on the number of 64k boundaries crossed.
Using a common function saves there being any typos in the 3 places
it is used.
Signed-off-by: David Laight
---
drivers/usb/host/xhci-ring.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git
From: Greg KH
> On Mon, Jan 27, 2014 at 04:06:22PM +0000, David Laight wrote:
> > Many of the net/usb ethernet drivers (including common ones like
> > the smsc95xx) will fail to transmit all packet length properly
> > when connected to a USB3 port (ie using the xhci driver)
From: Sarah Sharp
> On Wed, Jan 22, 2014 at 03:22:53PM -0800, walt wrote:
> > On 01/22/2014 12:56 PM, Sarah Sharp wrote:
> > > Walt, can you turn on xHCI debugging and look for whether the NEC host
> > > that worked with David's patch is a 1.0 host? You'll see a line like:
> > >
> > > // @%p = 0x%
From: Sarah Sharp
> Hi David,
>
> I've been thinking about this some more, and I'd like to propose a much
> simpler solution.
>
> The TD fragment rules didn't go into the xHCI specification until the
> 1.0 revision. The code that follows those rules only seems to trigger
> issues for 0.96 ASMed
node.on.net]
> Sent: 21 January 2014 02:34
> To: David Laight
> Subject: Re: xhci ASMedia lockups - a theory and a patch
>
> On Thursday 16 January 2014 08:59:34 you wrote:
> > > I've been having problems with a ax88179_178a locking up the whole host
> > > whe
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?
>
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
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
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
et.
It is important that all these patches be applied together.
More specifically the change xhci-ring.c must be applied AFTER the
change to usbnet.c.
Failure to do so will break some configurations including those using
the ax88179_178a usb ethernet on hosts with the Intel Panther Point
chipset (which
x27; scatter-gather lists. But and the moment the former
is (more or less) required to be infinite, and the limit of the latter
won't be reached by any code that sets the flag.
Signed-off-by: David Laight
---
drivers/net/usb/usbnet.c | 1 +
drivers/usb/host/xhci-ring.c | 12
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 +0000, 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
From: Peter Stuge
> But what about that alignment? It seems that userspace
> needs to start caring about alignment with xhci, right?
No because there is a copy_to/from_user() in the middle.
The ehci/ohci/uhci all require that fragments be a multiple of the
usb message size (512 bytes for USB2).
S
From: Sarah Sharp
> We need to step back and reassess the larger picture here, instead of
> trying to fire-fight all the regressions caused by the link TRB commit
> (35773dac5f86 "usb: xhci: Link TRB must not occur within a USB payload
> burst").
Some of the breakage seems to have been related to
From: Peter Stuge [mailto:pe...@stuge.se]
> > Userspace doesn't care since everything gets copied into aligned
> > kernel fragments - otherwise the other usb controllers wouldn't work.
>
> OK, but not so great if someone wants to squeeze the most performance
> possible out of USB also from userspa
From: Sarah Sharp
> 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
> > > iss
oller registers
Some controllers (eg ASMedia) do not support 64 bit accesses to
their internal registers even though they are 64bit capable.
32bit transfers in the correct order.
Signed-off-by: David Laight
---
drivers/usb/host/xhci.h | 40
1 file change
From: Sarah Sharp
> Yoma, can you apply this patch and see if it helps your issue?
Helped a lot on my amd system with the ASMedia controller.
David
...
> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> > index 64ea21971be2..74a69b887346 100644
> > --- a/drivers/usb/core/
From: David Laight
> From: Sarah Sharp
> > Yoma, can you apply this patch and see if it helps your issue?
>
> Helped a lot on my amd system with the ASMedia controller.
I lied :-)
Sometimes it is detected at 480MB - in which case it comes up immediately.
Other times it is detecte
From: Mark Lord
> On 14-02-01 09:18 AM, Ming Lei wrote:
> >
> > Even real regressions are easily/often introduced, and we are discussing
> > how to fix that. I suggest to unset the flag only for the known buggy
> > controllers.
>
> It is not the controllers that are particularly "buggy" here.
> Bu
From: renev...@internode.on.
> Hello guys,
>
> At this point it just looks like I have 2 problems:
>
> 1> The AX88179 won't initialize and operate properly when connected via the
> Asmedia 1042 (at least on my ASUS AMD 990FX based system) this appears to go
> back to at least kernel version 3.11
From: David Laight
> From: renev...@internode.on.
> But there are also further issues I'm about to look at.
> Short 'ping' requests work, but a 'netperf' tcp rr test with 8k blocks
> (which probably generates sg transmits) fails generating some
> 'TR
From: David Laight
> From: David Laight
> > From: renev...@internode.on.
> > But there are also further issues I'm about to look at.
> > Short 'ping' requests work, but a 'netperf' tcp rr test with 8k blocks
> > (which probably generates sg t
On one system (an amd motherboard with the ASMedia xhci controller)
I'm seeing almost back to back USB (7 or 8 a second) 'interrupt'
packets from an ax88179 Ge card.
It may be that other systems behave similarly.
I'm sure this hadn't used to happen!
I don't know what the interrupt status means, th
From: Markus Rechberger
> >> Dec 27 23:23:50 solist kernel: [ 36.118245] xhci_hcd :00:14.0: ERROR
> >> Transfer event TRB DMA
> ptr
> >
> > These messages might be harmless. The 3.0 kernel contains a fix for
> > Intel Panther Point xHCI hosts that suppresses those messages, commit
> > ad808
I've spent most of the day adding traces to the usbnet, xhci-ring and
ax88179_178a code to try to find out why the link doesn't come up quickly.
I've just found out something significant that someone else might
like to try and repeat.
If I add a trace print to xhci_queue_control_tx() is all seems
From: Dan Williams
> > Adding another list that will have its own set of bugs seems retrograde top
> > me.
>
> What bugs? Please be specific. The problem to be addressed is not
> the allocation of commands, but that timeouts of one command eat the
> timeout periods of subsequent commands. I'm
From: Mark Lord
> >> Which means that the controller is obeying the rules, and the software is
> >> wrong.
> ..
> > In this case, the bug has been worked around (not perfectly), but we've
> > had no customer reports that this is an issue. There is no user-visible
> > impact as far as we know. S
From: Kasberger Andreas
> What is still puzzling me is the fact that the host controller stops any
> communication.
> That means there is really electrically no communication (bulk_out) from HC
> to device anymore. It
> seems that the host controller has shut down communication port to one
> par
From: Sarah Sharp
> xHCI 1.0 hosts have a set of requirements on how to align transfer
> buffers on the endpoint rings called "TD fragment" rules. When the
> ax88179_178a driver added support for scatter gather in 3.12, with
> commit 804fad45411b48233b48003e33a78f290d227c8 "USBNET: ax88179_178a:
From: renev...@internode.on.net
> Messing with the Realtek nic driver didn't work my pc crashed soon after.
>
>
> It looks like i've hit on a stable combination at the moment. It's looking
> like either...
>
> * Passing "nomsi" as a kernel parameter has worked somehow, when doing
> /proc/interru
From: renev...@internode.on.
> I got a feeling if I plug the nic into the Asmedia again i'm still going to
> get a bunch of kevent 4 spam.
Did you see my message about those yesterday?
Try adding a printk() to the usbnet_write_cmd_async() code paths
called from ax88179's set_multicast code.
I f
201 - 300 of 515 matches
Mail list logo
