> You're right. I do wish the spec had been written more clearly.
I've read a lot of hardware specs in my time ...
> > Reading it all again makes me think that a LINK trb is only
> > allowed on the burst boundary (which might be 16k bytes).
> > The only real way to implement that is to ensure th
here later.
Signed-off-by: David Laight
---
This patch will only apply cleanly if my earlier patch that affects
the previous line has also been applied.
drivers/usb/host/xhci-ring.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
ind
> > If all the fragments are larger than the MBP (assume 16k) then
> > that would be relatively easy. However that is very dependant
> > on the source of the data. It might be true for disk data, but
> > is unlikely to be true for ethernet data.
>
> I don't quite understand your point. Are you sa
> On Fri, Nov 08, 2013 at 11:07:41AM -0000, David Laight wrote:
> > > While this change improves things a lot (it runs for 20 minutes rather
> > > than
> > > a few seconds), there is still something else wrong.
> >
> > Almost certainly caused by an un
> > That's one way to do it. Or you could allow a Link TRB at an
> > intermediate MBP boundary.
>
> I like this idea instead. The xHCI driver should be modified to be able
> to handle link TRBs in the middle of the segments (the cancellation code
> would have to be touched as well). We would ke
> > Since you don't really want to do all the work twice, the sensible
> > way is to add each input fragment to the ring one a time.
> > If you need to cross a link TRB and the last MBP boundary is within
> > the previous data TRB then you can split the previous data TRB at the
> > MBP boundary and
> > that doesn't matter; we don't get an interrupt when a ring segment is
> > crossed. Instead we set the interrupt-on-completion flag on the last
> > TRB of the TD, not on any earlier fragment or link TRB.
>
> That's because you don't worry about handling URBs which require too
> many TRBs (i.e.
> From: Sarah Sharp [mailto:sarah.a.sh...@linux.intel.com]
>
> On Thu, Oct 31, 2013 at 04:16:14PM -0000, David Laight wrote:
> > Code was recently added to the xhci driver to dynamically add extra ring
> > segments if there is insufficient space for all the fragments of t
> Greg KH wrote:
> On Tue, Nov 12, 2013 at 01:58:05PM -, David Laight wrote:
> >
> > There needs to be a wmb() barrier between the write to the cycle bit
> > in the first TRB and the write to the doorbell register.
> >
> > Since it isn't neede
Self nak - I'll send a v2.
> If URB_ZERO_PACKET is set on a transfer that is an integral number
> of maximum length packets (1k for USB3 bulk) then an additional
> zero length fragment must be sent.
...
> if (urb->num_sgs == 0) {
> sg = NULL;
> addr = (u64)urb->tr
g the logic as well.
In particular we note that the number of TRB passed to prepare_ring()
need only be an upper limit on the number required. However we do try
to only request 1 TRB when we know one is sufficient.
Signed-off-by: David Laight
---
Change for v2:
- Ensure we check there is space for
> From: Oliver Neukum
>
> Just remove the conditional compilation.
>
> Signed-off-by: Oliver Neukum
> ---
> drivers/usb/host/ohci-hcd.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> index 501ecea..de0e3e4 100644
> ---
> if I want to convert UHCI to full dynamic debugging, how
> should I deal with the debug module parameter?
Change the default state of the flag?
David
> > > if I want to convert UHCI to full dynamic debugging, how
> > > should I deal with the debug module parameter?
> >
> > Change the default state of the flag?
>
> I could, but how would that help? I need to have the
> basic decision whether to retain the facility.
> Then, if dynamic debugging i
> > I have a USB 3.0 hub (not with me right now), which has either three or
> > four USB 3.0 ports exposed, and seven USB 2.0 ports. The OS sees it as
> > one USB 3.0 hub and two USB 2.0 hubs chained together. My guess is that
> > the manufacturer wanted to say they had a "seven port USB 3.0 hub"
> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: 13 November 2013 16:21
> To: David Laight
> Cc: Sarah Sharp; net...@vger.kernel.org; linux-usb@vger.kernel.org
> Subject: RE: [PATCH] usb: xhci: Link TRB must not occur with a USB payload
write_isoc_trbs() to allow
consistent naming.
Signed-off-by: David Laight
---
drivers/usb/host/xhci-ring.c | 16
drivers/usb/host/xhci.c | 8
drivers/usb/host/xhci.h | 8
3 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/usb
> From: Oliver Neukum
>
> To allow a full switch to dynamic debugging make the
> debug parameter conditional on defined(DEBUF) || defined(DYNAMIC_DEBUG)
This version still contains ugly (and unnecessary) #if in the code.
...
Both debug and errbuf are 0 so this would be compiled out:
> +#if def
> From: Sarah Sharp
> On Wed, Nov 13, 2013 at 12:28:09PM -, David Laight wrote:
> > If URB_ZERO_PACKET is set on a transfer that is an integral number
> > of maximum length packets (1k for USB3 bulk) then an additional
> > zero length fragment must be sent.
> >
&g
> From: Sarah Sharp [mailto:sarah.a.sh...@linux.intel.com]
>
> On Mon, Nov 11, 2013 at 12:26:54PM -0000, David Laight wrote:
> >
> > Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
> > can only occur at a boundary between underlying USB fram
> From: Of Hans de Goede
>
> The iu struct definitions are usb packet definitions, so no alignment should
> happen. Notice that assuming 32 bit alignment this does not make any
> difference at all.
>
> Signed-off-by: Hans de Goede
> ---
> include/linux/usb/uas.h | 10 +-
> 1 file change
> From: Hans de Goede
>
> Copy the sg alignment trick from the usb-storage driver, without this I'm
> seeing intermittent errors when using uas devices with an ehci controller.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/usb/storage/uas.c | 18 ++
> 1 file changed, 18 inser
> From: Hans de Goede
> Sent: 15 November 2013 15:06
> To: Sarah Sharp
> Cc: linux-usb@vger.kernel.org; Gerd Hoffmann; Alan Stern; Hans de Goede
> Subject: [PATCH 01/68] xhci: fix usb3 streams
>
> From: Gerd Hoffmann
>
> xhci maintains a radix tree for each stream endpoint because it must
> be a
> From: Hans de Goede [mailto:hdego...@redhat.com]
> On 11/15/2013 04:29 PM, David Laight wrote:
> >> From: Of Hans de Goede
> >>
> >> The iu struct definitions are usb packet definitions, so no alignment
> >> should
> >> happen. Notice th
> It doesn't look like the networking subsystem (which seems to be the
> code you're most familiar with) uses packed, but plenty of other
> subsystems do.
I'm necessarily trying to change the world here :-) But ...
I suspect a few places have got caught out where 32bit values
get 16bit aligned an
> On 11/15/2013 04:46 PM, David Laight wrote:
> >> From: Hans de Goede
> >> Sent: 15 November 2013 15:06
> >> To: Sarah Sharp
> >> Cc: linux-usb@vger.kernel.org; Gerd Hoffmann; Alan Stern; Hans de Goede
> >> Subject: [PATCH 01/68] xhci
> > But the minimum fragment size is (probably) 4k.
> > For the network stack an OUT transfer might have a lot (and I mean lots)
> > of fragments (there may be constraints, and linearising the skb is a
> > option).
> [...]
>
> The maximum number of fragments in the skb is going to be 17 (includin
> -Original Message-
> From: Ben Hutchings [mailto:bhutchi...@solarflare.com]
> Sent: 18 November 2013 15:03
> To: David Laight
> Cc: Alan Stern; Sarah Sharp; net...@vger.kernel.org; linux-usb@vger.kernel.org
> Subject: Re: [PATCH] usb: xhci: Link TRB must not occur
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> On Tue, 19 Nov 2013, Sarah Sharp wrote:
>
> > The xHCI driver can limit the number of sg-list entries through
> > hcd->self.sg_tablesize. It's currently set to ~0, which is "however
> > many entries you want. You could set that to the numbe
> From: Sarah Sharp
...
> (Also, usb-storage aligns the block sizes to 512K, which explains why
> we've never had an issue with TD fragments with that driver.)
What is a 'block' in that context?
512K sounds more like the value that very long transfers get chopped
up into. With 4k pages that might
> From: Eric Dumazet [mailto:eric.duma...@gmail.com]
> On Wed, 2013-11-20 at 09:36 +, David Laight wrote:
>
> > Ben said the largest number of fragments from the current network
> > stack will be 17, and that none of them will cross 32k boundaries.
> > So the ne
> From: Sarah Sharp [mailto:sarah.a.sh...@linux.intel.com]
> On Wed, Nov 20, 2013 at 09:36:11AM -, David Laight wrote:
> > > From: Alan Stern [mailto:st...@rowland.harvard.edu]
> > > On Tue, 19 Nov 2013, Sarah Sharp wrote:
> > >
> > > > The xHCI d
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> On Wed, 20 Nov 2013, David Laight wrote:
>
> > > From: Sarah Sharp
> > ...
> > > (Also, usb-storage aligns the block sizes to 512K, which explains why
> > > we've never had an issue with TD
> Ok, so the networking layer should be fine. However, with the current
> patch, if the mass storage driver sends down a scatter-gather list
> that's bigger than a ring segment, or needs to be split up so it doesn't
> cross 64K boundaries, then the URB submission will fail. We don't want
> that t
> > My suspicion is that long SG lists are unusual - otherwise the
> > ring expansion code would have been needed much earlier.
> >
> > Can anyone remember whether that was needed because of long SG lists
> > or because of large numbers of outstanding requests?
> >
> > I've seen it for network card
> From: Alan Stern
> On Mon, 25 Nov 2013, Xenia Ragiadakou wrote:
>
> > > You can simplify part of the problem by not allowing an endpoint to be
> > > reset if it has any pending URBs. Just fail the reset in this case.
> >
> > Yes, you are right since, from what i understand, it is the
> > respon
> From: Of Roger Quadros
> With u-boot 2013.10, USB devices are sometimes not detected
> on OMAP4 Panda. To make us independent of what bootloader does
> with the USB Host module, we must RESET it to get it to a known
> good state. This patch Soft RESETs the USB Host module.
...
> +++ b/drivers/mfd
> From: Mark Lord
> Sent: 30 November 2013 02:59
> To: Sarah Sharp; David Laight
> Cc: David Miller; eric.duma...@gmail.com; ming@canonical.com;
> net...@vger.kernel.org; linux-
> u...@vger.kernel.org
> Subject: Re: net/usb/ax88179_178a driver broken in linux-3.12
>
> From: Roger Quadros [mailto:rog...@ti.com]
> On 11/29/2013 03:17 PM, David Laight wrote:
...
> >> + timeout = jiffies + msecs_to_jiffies(100);
> >> + while (!(usbhs_read(omap->uhh_base, OMAP_UHH_SYSSTATUS)
> >> + & OMAP_UHH_SYSSTATUS
> > +void usbnet_link_updated(struct usbnet *dev)
> > +{
> > + complete(&dev->link_update_completion);
> > +}
> > +EXPORT_SYMBOL_GPL(usbnet_link_updated);
>
> Isn't that a bit too trivial to get the _GPL version?
Particularly if the usb infrastructure (that I presume this
is part of) might be r
> On Wed, Oct 10, 2012 at 6:08 PM, Oliver Neukum wrote:
>
> > A reset always applies to the whole device. Resets are used in error
> > handling of block devices (storage and uas). If you reset a device,
> > pre_reset() and post_reset() of all interfaces need to be called. So they
> > are part of
> Looks the problem is worse than above, not only bitfields are affected, the
> adjacent fields might be involved too, see:
>
>http://lwn.net/Articles/478657/
Not mentioned in there is that even with x86/amd64 given
a struct with the following adjacent fields:
char a;
> We're only passing the two high bits of an integer. It works for little
bytes
> endian but not for big endian.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
> index 0969905..03e8a15 100644
> --- a
> From: Peter Chen
>
> According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB
> register error issue", All USB register write operations must
> use the ARM SWP instruction. So, we implement special hw_write
> and hw_test_and_clear for imx28.
>
> Discussion for it at below:
> http://marc
> > We can't guarantee there is no other access on the AHB without disable
> > interrupt, would you think below operation will be more efficient than swp,
> > or any better solutions?
I don't know whether it would be more or less efficient, it rather
depends on the finer points of the architecture
I sent a few patches to the xhci driver at the beginning of November.
One of them has been pushed to 3.13 and 3.12.
If it possible to find out if the others are queued somewhere or
whether I should resubmit them?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-u
> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> On Fri, Dec 06, 2013 at 12:55:23AM -0500, Mark Lord wrote:
> > On 13-12-02 04:42 PM, Greg Kroah-Hartman wrote:
> > > On Mon, Dec 02, 2013 at 12:49:08PM -0800, Sarah Sharp wrote:
> > >> The following changes since commit
> > >> c24cb6
> From: Sarah Sharp
> Sent: 06 December 2013 17:03
> To: Mark Lord
> Cc: Greg Kroah-Hartman; linux-usb@vger.kernel.org; David Laight;
> net...@vger.kernel.org
> Subject: Re: [GIT PULL] xhci: Regression fix for 3.13.
>
> On Fri, Dec 06, 2013 at 12:55:23AM -0500, Mark Lor
it repository at:
> >> > >>
> >> > >>
> >> > >> git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git
> >> > >> tags/for-usb-linus-2013-12-02
> >> > >
> >> > > Pulled and pushed out, thanks.
>
> From: Thomas Pugliese
> Sent: 09 December 2013 19:11
> To: linux-usb@vger.kernel.org
> Cc: gre...@linuxfoundation.org; Thomas Pugliese
> Subject: [PATCH] usb: wusbcore: fix short transfers
>
> If a URB is broken up into multiple transfer segments and a short
> transfer occurs in any segment othe
> From: Freddy Xin
> On 2013年12月10日 09:01, David Miller wrote:
> > From: fre...@asix.com.tw
> > Date: Fri, 6 Dec 2013 17:58:18 +0800
> >
> >> From: Freddy Xin
> >>
> >> The AX88179_178A has a hardware feature that it can insert a 2-bytes pseudo
> >> header in front of each received frame by setti
> From: fre...@asix.com.tw
...
> - skb = __netdev_alloc_skb_ip_align(dev->net, size, flags);
> + if (dev->driver_info->flags & FLAG_HW_IPALIGN)
> + skb = __netdev_alloc_skb(dev->net, size, flags);
> + else
> + skb = __netdev_alloc_skb_ip_align(dev->net, size, fla
> From: Of Wang, Lin X
> Sent: 15 December 2013 14:21
> To: Sarah Sharp (sarah.a.sh...@linux.intel.com)
> Cc: linux-usb@vger.kernel.org
> Subject: [PATCH] xhci: fix array index out of the bounds in function
> last_trb() and
> last_trb_on_last_seg()
>
> In function last_trb() and last_trb_on_last_
> From: Freddy Xin
> On 2013年12月13日 18:36, David Laight wrote:
> >> From: fre...@asix.com.tw
> > ...
> >> - skb = __netdev_alloc_skb_ip_align(dev->net, size, flags);
> >> + if (dev->driver_info->flags & FLAG_HW_IPALIGN)
> >&
> From: Krzysztof Opasiak
> use sizeof to determine size of memory to copy instead of
> using hard coded values.
...
> - memcpy(&f->attr.net.dev_addr, dev_addr, 6);
> + memcpy(&f->attr.net.dev_addr, dev_addr, sizeof(*dev_addr));
It generally looks better if you use the size of the destin
> From: Wang, Lin X
> 2013/12/16 David Laight :
> >> From: Of Wang, Lin X
> >> Sent: 15 December 2013 14:21
> >> To: Sarah Sharp (sarah.a.sh...@linux.intel.com)
> >> Cc: linux-usb@vger.kernel.org
> >> Subject: [PATCH] xhci: fix array index
> I know all these difference clearly, inc_deq() is indeed a common
> function for different rings, but lasr_trb() & last_trb_on_last_seg()
> inside it use different condition to determine the last trb in an
> event ring and an non-event ring; and sorry, i still not find why last
> trb in an event
> From: Wang, Lin X
> David is right, this patch may lead to the last trb in an event ring
> unprocessed according to the
> current logic, you can reject this patch, although I think index
> out-of-bounds is reasonable.
>
> If applying this patch, then corresponding function(inc_deq()) should b
> From: Sarah Sharp
> On Mon, Dec 16, 2013 at 03:20:28PM -, David Laight wrote:
> > > I know all these difference clearly, inc_deq() is indeed a common
> > > function for different rings, but lasr_trb() & last_trb_on_last_seg()
> > > inside it use differen
> > Then the inc_deq() code could just be:
> >
> > ring->deq_updates++;
> > ring->num_trbs_free++;
> >
> > if (last_trb(xhci, ring, ring->deq_seg, ++ring->dequeue)) {
> > ring->deq_seg = ring->deq_seg->next;
> > ring->dequeue = ring->deq_seg->trbs;
> >
and xhci_initialize_ring_info()
as these are only called for new rings and always passed 1 (TRB_CYCLE).
Signed-off-by: David Laight
---
Changes for v2:
1: Adjusted so that is applies to HEAD
2: Added signed-off
Changes for v3:
1: Changed for additional lines (assignd to new_cycle_state).
2: Removed
> From: Of David Laight
> Using TRB_CYCLE makes it clearer that the ring->cycle_state value is used when
> writing to the actual ring itself.
FWIW this patch is against Linus's tree.
This hunk probably fails to apply to some trees because the patch
to force TRB_CYCLE to be lit
This saves a kzalloc() call on every transfer and some memory
indirections.
The only possible downside is for isochronous tranfers with 64 td
when the allocate is 8+4096 bytes (on 64bit systems) so requires
an additional page.
Signed-off-by: David Laight
---
v2: Added signed-off-by line
other places the doobell is rung
(because the ring contents haven't been changed) add it to
giveback_first_trb() rather than somewhere later.
Signed-off-by: David Laight
---
Changes for v2:
- Comment why the wmb() is needed.
drivers/usb/host/xhci-ring.c | 6 ++
1 file changed, 6 insertion
write_isoc_trbs() to allow
consistent naming.
Signed-off-by: David Laight
---
Changes for v2:
- Modified so that it applies before one of my other patches.
(which also needs a v2 now)
drivers/usb/host/xhci-ring.c | 16
drivers/usb/host/xhci.c | 8
drivers/usb/host
> From: Sarah Sharp
> Hi David,
>
> This patch is fine in general, however I can't seem to get it to apply.
> I tried 3.12, 3.13-rc4, and my for-usb-next-queue branch, and `git am`
> failed on all three kernels. Can you rebase this against either
> 3.13-rc4 or my for-usb-next-queue branch?
I've
Rename the constants XHCI_TRUST_TX_LENGTH to XHCI_TRUST_RX_LENGTH
and COMP_SHORT_TX to COMP_SHORT_RX to avoid any confusion that
they might apply to transmit transfers.
Signed-off-by: David Laight
---
I can't actually see any driver that requires this quirk!
Note that this replaces part o
Don't trace unexpected incomplete receives if the XHCI_TRUST_RX_LENGTH is set.
Don't trace short receives if URB_SHORT_NOT_OK is set. Short receives
are normal for USB ethernet devices.
Ratelimit both traces.
Signed-off-by: David Laight
---
This is dependent on my previous patch
Code is correct since the value and final target are both little-endian.
Signed-off-by: David Laight
---
drivers/usb/host/xhci-ring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 2315be1..0420daf 100644
> From: Freddy Xin
> On 2013年12月16日 18:09, David Laight wrote:
> >> I was thinking of something like: skb = netdev_alloc_skb(dev, length
> >> + dev->skb_align, gfp); if (NET_IP_ALIGN && skb && !(ev->driver_flags
> >> & FLAG_HW
> From: Krzysztof Opasiak
> Replace strings, functions, configs strings placed
> everywhere in code with macro defintions STRINGS_DIR,
> FUNCTIONS_DIR and CONFIGS_DIR.
I'm not convinced this is an improvement, do you have a further
change in mind?
It also isn't entirely clear there aren't some oth
> From: Chris Sykes
> I have a user space application which communicates with an embedded
> micro-controller over USB via an FTDI FT232H chip.
>
> I'm seeing occasional data loss while reading data transmitted by the
> micro, and I believe that when this occurs the FTDI UART Rx fifo is
> being ove
> From: David Laight
> Only receive TD can have a transfer length less than the transfer size,
> so rename COMP_SHORT_TX to COMP_SHORT_RX, XHCI_TRUST_TX_LENGTH to
> XHCI_TRUST_RX_LENGTH.
> handle_tx_event() is called for both receive and transmit completions
> so rename to
> From: Rashika Kheria
> Include header file include/linux/usb.h in include/linux/usb/hcd.h
> because structures usb_device, usb_host_config and usb_interface have
> their definitions in include/linux/usb.h.
>
> This eliminates the following warning in include/linux/usb/hcd.h:
> include/linux/usb/
> > These warning are non-default GCC warnings. These can be seen either
> > by adding W=1 while running make (i.e. make W=1) or adding
> > -Wmissing-prototypes in KBUILD_CFLAGS in the toplevel Makefile.
>
> By default, we don't care about 'W=1' warnings, as no one sees them, and
> they don't matt
> From: Steve Calfee
> On Wed, Dec 18, 2013 at 3:24 AM, David Laight wrote:
> >
> > This saves a kzalloc() call on every transfer and some memory
> > indirections.
> >
> > The only possible downside is for isochronous tranfers with 64 td
> > when the
> From: David Cohen
> On Wed, Dec 18, 2013 at 11:24:47AM -, David Laight wrote:
> > This saves a kzalloc() call on every transfer and some memory
> > indirections.
> >
> > The only possible downside is for isochronous tranfers with 64 td
> > when the alloca
> From: Josh Triplett
> On Thu, Dec 19, 2013 at 05:33:09PM -, David Laight wrote:
> > OTOH just including extra headers isn't ideal - it can considerably
> > slow down the compilation time. There are many subsystems that don't
> > really separate their interna
> From: Greg Kroah-Hartman
> CONFIG_USB_DEBUG is going away, so remove the few places in the USB core
> that relied on them.
>
> This means that we always now do the "debug" checks for every urb
> submitted, which is a good idea, as who knows how many driver bugs we
> have been ignoring when peopl
> From: Peter Chen
> Sent: 20 December 2013 07:52
> Change "high speed" to "HS"
> Change "non-high speed" to "FS/LS"
>
> Implementation of notify_suspend and notify_resume will be different
> according to mxs_phy_data->flags.
>
> Signed-off-by: Peter Chen
> ---
> drivers/usb/phy/phy-mxs-usb.c |
> From: Greg Kroah-Hartman
...
> > ...
> > > /* Check that the pipe's type matches the endpoint's type */
> > > if (usb_pipetype(urb->pipe) != pipetypes[xfertype])
> >
> > It looks as though it ought to be possible to make that check:
> > if (unlikely(xfertype != urb->pipe->valid_xfertype))
> From: David Cohen
> On Fri, Dec 20, 2013 at 09:26:35AM -, David Laight wrote:
> > > From: David Cohen
> > The effect of this change is really to remove the first allocation and
> > add 8 bytes (or maybe a pointer) to the start of the second one.
> > So it i
> From: walt
...
> /* Accept arbitrarily long scatter-gather lists */
> - hcd->self.sg_tablesize = ~0;
> + hcd->self.sg_tablesize = 31;
Even if that reduces the number of fragments passed to the xhci driver
it may not be enough to limit the actual number of fragments that
need
> From: Alan Stern
> Subject: Re: Bug#733826: crazy loop "xhci_hcd Too many fragments"
>
> On Mon, 6 Jan 2014, Ben Hutchings wrote:
>
> > On Sat, 2014-01-04 at 05:44 +0800, jida...@jidanni.org wrote:
...
> > > # cat /var/log/syslog
> > >
> > > Jan 1 06:57:38 jidanni5 ntpd[2822]: Listen normally
> From: 'David Cohen'
> On Mon, Jan 06, 2014 at 09:26:20AM +0000, David Laight wrote:
> > > From: David Cohen
> > > On Fri, Dec 20, 2013 at 09:26:35AM -, David Laight wrote:
> > > > > From: David Cohen
> > > > The effect of this chan
> From: Of Holger Freyther
> > xhci_hcd does not work with the Canon Lide scanners and has issues
> > with the suspend/resume handling. My Acer Aspire S5 notebook only
> > exposes USB3.0 ports and the distribution kernels generally have
> > xhci_hcd enabled and I don't have any USB3.0 hardware eith
> From: walt
...
> Thanks Sarah. dmesg0 is from the diagnostic patch only. dmesg1 has all
> three patches applied. Some of the messages in dmesg1 fell off the end of
> the kernel buffer, so I may need to make the buffer larger next time but
> I'll need a reminder of how to do it.
>
> As you sus
The dmesg contains:
[ 538.728064] EXT4-fs warning (device dm-0): ext4_end_bio:316: I/O error
writing to inode 23330865 (offset 0 size 8388608 starting block 812628)
An 8MB transfer will need at least 128 ring entries (TRB) even if the request
is a single contiguous memory block.
Are you using
> From: 'David Cohen'
...
> > > The new kmalloc is going to be "n * sizeof(struct) - n * sizeof(pointer)"
> > > bigger. I don't know what is the usual range of values for "n", but my
> > > experience with android devices with non-abundant memory size is that
> > > they are sensible to kmalloc > PAG
> From: tatxarata
> Since reporting this bug I've invested some time to get myself familiar
> with USB protocol and analyzed attached capture files. It seems like
> device resetoccurs after device returns urb_status=-75 (-EOVERFLOW).
...
> In case of USB2.0 host<->device traffic looks pretty the sa
> From: 'David Cohen'
...
> I actually don't know what's the regular range of 'td_cnt'. But what got my
> attention was this comment from patch description:
>
> "The only possible downside is for isochronous tranfers with 64 td
> when the allocate is 8+4096 bytes (on 64bit systems) so requires
> a
> From: Sarah Sharp
> On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote:
> > On 01/07/2014 01:21 PM, Sarah Sharp wrote:
> >
> > > Can you please try the attached patch, on top of the previous three
> > > patches, and send me dmesg?
> >
> > Hi Sarah, I just now finished running 0001-More-debuggin
> From: Alan Stern
>
> This may be a foolish question, but why is xhci-hcd using no-op TRBs in
> the first place?
Because it can't write in a link TRB because other parts of the
code use link TRBs to detect the end of the ring.
The problem is that it can't put a link TRB in the middle of
a chain
> From: Alan Stern
> On Wed, 8 Jan 2014, David Laight wrote:
>
> > > From: Alan Stern
> > >
> > > This may be a foolish question, but why is xhci-hcd using no-op TRBs in
> > > the first place?
> >
> > Because it can't write in a link T
> From: Peter Chen
...
> > > >> +#ifdef CONFIG_SOC_IMX28
> > > >> +static inline void imx28_ehci_writel(const unsigned int val,
> > > >> + volatile __u32 __iomem *addr)
> > > >> +{
> > > >> + __asm__ ("swp %0, %0, [%1]" : : "r"(val), "r"(addr));
> > > >> +}
> > > >> +#else
> > > >
> From: Sarah Sharp
> Currently prepare_ring() returns -ENOMEM if the urb won't fit into a
> single ring segment. usb_sg_wait() treats this error as a temporary
> condition and will keep retrying until something else goes wrong.
Even if it were a temporary condition then an immediate retry
is rat
> From: walt
...
> I'm still wondering if I'm suffering from hardware quirks. From the
> first day I installed my usb3 adapter card and the usb3 disk docking
> station I've noticed some quirky behavior.
Ah - this isn't an 'on chip' usb3 adapter.
Some kind of PCIe card ?
> e.g. I boot the machine
From: Alan Stern
> On Thu, 9 Jan 2014, David Laight wrote:
>
> > > From: Sarah Sharp
> > > Currently prepare_ring() returns -ENOMEM if the urb won't fit into a
> > > single ring segment. usb_sg_wait() treats this error as a temporary
> > > condit
From: Sarah Sharp
> On Thu, Jan 09, 2014 at 10:56:44AM -0500, Alan Stern wrote:
> > On Thu, 9 Jan 2014, David Laight wrote:
> >
> > > From: Alan Stern
...
> > > > > Of course, if this is the pagedaemon trying to write out
> > > > > pages in
From: Peter Chen
...
> +#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 __iomem *addr)
> +{
> +}
> +#endif
> +
> +static
101 - 200 of 515 matches
Mail list logo
