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_remainder() instead
> >>> of xhci_td_remainder().
> >>
> David, I
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_remainder() instead
of xhci_td_remainder().
David, I tried the one-liner below,
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_remainder() instead
>>> of xhci_td_remainder().
>>
>> Why? Walt has a 0.96 xHCI host
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_remainder() instead
> > of xhci_td_remainder().
>
> Why? Walt has a 0.96 xHCI host controller, and the format for how to
> calculate the TD
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_remainder() instead
of xhci_td_remainder().
Why? Walt has a 0.96 xHCI host controller, and the format for how to
calculate the TD remainder
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_remainder() instead
of xhci_td_remainder().
Why? Walt has a 0.96 xHCI host controller, and the format
On Mon, Jan 20, 2014 at 11:21:14AM +, David Laight wrote:
> 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
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 was the usual html
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 did notice that the lockup occurred
On Mon, Jan 20, 2014 at 11:21:14AM +, David Laight wrote:
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
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 did notice that the lockup occurred only when
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 was the usual html corruption, so I
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 was the usual html corruption, so I found the original
On 01/17/2014 06:34 AM, David Laight wrote:
> 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
On 01/17/2014 06:34 AM, David Laight wrote:
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
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 was the usual html corruption, so I found the original on
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
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 of
On Tue, Jan 14, 2014 at 01:27:25PM -0800, walt wrote:
> On 01/14/2014 09:20 AM, Sarah Sharp wrote:
> > On Mon, Jan 13, 2014 at 03:39:07PM -0800, walt wrote:
>
> >> Sarah, I just fixed my xhci bug for US$19.99 :)
> >>
> >> #lspci | tail -1
> >> 04:00.0 USB controller: NEC Corporation uPD720200 USB
On Tue, Jan 14, 2014 at 01:27:25PM -0800, walt wrote:
On 01/14/2014 09:20 AM, Sarah Sharp wrote:
On Mon, Jan 13, 2014 at 03:39:07PM -0800, walt wrote:
Sarah, I just fixed my xhci bug for US$19.99 :)
#lspci | tail -1
04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
On 01/14/2014 09:20 AM, Sarah Sharp wrote:
> On Mon, Jan 13, 2014 at 03:39:07PM -0800, walt wrote:
>> Sarah, I just fixed my xhci bug for US$19.99 :)
>>
>> #lspci | tail -1
>> 04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller
>> (rev 03)
>>
>> This new NEC usb3 controller
On Mon, Jan 13, 2014 at 03:39:07PM -0800, walt wrote:
> 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
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
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 one for the team by
On Mon, Jan 13, 2014 at 03:39:07PM -0800, walt wrote:
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.
On 01/14/2014 09:20 AM, Sarah Sharp wrote:
On Mon, Jan 13, 2014 at 03:39:07PM -0800, walt wrote:
Sarah, I just fixed my xhci bug for US$19.99 :)
#lspci | tail -1
04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller
(rev 03)
This new NEC usb3 controller does
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 one for the team" by
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 one for the team by buying new hardware
On Thu, 9 Jan 2014, Sarah Sharp wrote:
> > I can't see anything obvious either.
> > However there is no response to the 'stop endpoint' command.
> > Section 4.6.9 (page 107 of rev1.0) states that the controller will complete
> > any USB IN or OUT transaction before raising the command completion
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
On 01/09/2014 03:50 PM, Sarah Sharp wrote:
>>> On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote:
>>
>> The aftermarket usb3 adapter card and the usb3 outboard hard-drive docking
>> station are the only two usb3 devices I have.
>>
>> I've wondered if my xhci problems might be caused by
On 01/09/2014 03:50 PM, Sarah Sharp wrote:
On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote:
The aftermarket usb3 adapter card and the usb3 outboard hard-drive docking
station are the only two usb3 devices I have.
I've wondered if my xhci problems might be caused by hardware quirks, and
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 asmedia
On Thu, 9 Jan 2014, Sarah Sharp wrote:
I can't see anything obvious either.
However there is no response to the 'stop endpoint' command.
Section 4.6.9 (page 107 of rev1.0) states that the controller will complete
any USB IN or OUT transaction before raising the command completion event.
[Walt, please use reply-all to keep the list in the loop, thanks.]
On Wed, Jan 08, 2014 at 04:09:14PM +, David Laight wrote:
> > 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
On 01/09/2014 02:05 AM, David Laight wrote:
>> 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
> 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
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
On 01/09/2014 02:05 AM, David Laight wrote:
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
[Walt, please use reply-all to keep the list in the loop, thanks.]
On Wed, Jan 08, 2014 at 04:09:14PM +, David Laight wrote:
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 01/03/2014 03:29 PM, Sarah Sharp wrote:
> I'll let you know when I have some diagnostic patches ready.
Hi Sarah. I see today gregkh committed the patches you've already sent
me, so I assume someone (other than me) has tested those patches and
discovered some benefit from them?
I'm still
> 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 TRB because other parts of the
> > code use link TRBs to detect
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 TRB because other parts of the
> code use link TRBs to detect the end of the ring.
>
> The
> 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
On Tue, 7 Jan 2014, Sarah Sharp wrote:
> 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
> 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
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-debugging.patch for the
On Tue, 7 Jan 2014, Sarah Sharp wrote:
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
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 of
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 TRB because other parts of the
code use link TRBs to detect the end of the ring.
The problem is that
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 TRB because other parts of the
code use link TRBs to detect the end of the ring.
On 01/03/2014 03:29 PM, Sarah Sharp wrote:
I'll let you know when I have some diagnostic patches ready.
Hi Sarah. I see today gregkh committed the patches you've already sent
me, so I assume someone (other than me) has tested those patches and
discovered some benefit from them?
I'm still
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-debugging.patch for the
> first time.
On Tue, Jan 07, 2014 at 12:00:00PM -0800, walt wrote:
> Okay, I used log_buf_len to make dmesg bigger and now I think I have
> the whole thing. It's attached.
Walt, can you make sure the patch I sent you was applied? The output
doesn't look like it is.
Sarah Sharp
--
To unsubscribe from this
On Tue, Jan 07, 2014 at 01:58:32PM +, David Laight wrote:
> 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
On Tue, Jan 07, 2014 at 05:29:48AM -0800, walt wrote:
> On 01/06/2014 04:31 PM, Sarah Sharp wrote:
> > Hi Walt,
> >
> > I have a couple of patches for you to test.
>
> > Please only apply the first patch (which is diagnostic only), trigger
> > your issue, and send me the resulting dmesg. Then
Okay, I used log_buf_len to make dmesg bigger and now I think I have
the whole thing. It's attached.
dmesg2.gz
Description: application/gzip
On 01/07/2014 05:58 AM, David Laight wrote:
> 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
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: 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
On 01/06/2014 04:31 PM, Sarah Sharp wrote:
> On Fri, Jan 03, 2014 at 03:29:29PM -0800, Sarah Sharp wrote:
>> With the dmesg, I can finally see what happened:
>>
>> [ 188.703059] xhci_hcd :03:00.0: Cancel URB 8800b7d2e0c0, dev 1, ep
>> 0x2, starting at offset 0xbb7b9000
>> [
On 01/06/2014 04:31 PM, Sarah Sharp wrote:
On Fri, Jan 03, 2014 at 03:29:29PM -0800, Sarah Sharp wrote:
With the dmesg, I can finally see what happened:
[ 188.703059] xhci_hcd :03:00.0: Cancel URB 8800b7d2e0c0, dev 1, ep
0x2, starting at offset 0xbb7b9000
[ 188.703072] xhci_hcd
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
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
On 01/07/2014 05:58 AM, David Laight wrote:
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
Okay, I used log_buf_len to make dmesg bigger and now I think I have
the whole thing. It's attached.
dmesg2.gz
Description: application/gzip
On Tue, Jan 07, 2014 at 05:29:48AM -0800, walt wrote:
On 01/06/2014 04:31 PM, Sarah Sharp wrote:
Hi Walt,
I have a couple of patches for you to test.
Please only apply the first patch (which is diagnostic only), trigger
your issue, and send me the resulting dmesg. Then try applying
On Tue, Jan 07, 2014 at 01:58:32PM +, David Laight wrote:
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)
On Tue, Jan 07, 2014 at 12:00:00PM -0800, walt wrote:
Okay, I used log_buf_len to make dmesg bigger and now I think I have
the whole thing. It's attached.
Walt, can you make sure the patch I sent you was applied? The output
doesn't look like it is.
Sarah Sharp
--
To unsubscribe from this
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-debugging.patch for the
first time. The
On Fri, Jan 03, 2014 at 03:29:29PM -0800, Sarah Sharp wrote:
> On Fri, Jan 03, 2014 at 01:21:18PM -0800, walt wrote:
> > I'm so sorry Sarah, that was another mistake. The mistake is so stupid I'm
> > not
> > going to publish it here :(
> >
> > Once I finally ran the kernel with debugging
> 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: 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 to be
On Fri, Jan 03, 2014 at 03:29:29PM -0800, Sarah Sharp wrote:
On Fri, Jan 03, 2014 at 01:21:18PM -0800, walt wrote:
I'm so sorry Sarah, that was another mistake. The mistake is so stupid I'm
not
going to publish it here :(
Once I finally ran the kernel with debugging actually compiled
On 14-01-03 10:40 AM, walt wrote:
> On 01/02/2014 11:15 AM, Sarah Sharp wrote:
>> On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
>>> On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
3.12-stable review patch. If anyone has any objections, please let me
know.
On 14-01-03 10:40 AM, walt wrote:
On 01/02/2014 11:15 AM, Sarah Sharp wrote:
On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
3.12-stable review patch. If anyone has any objections, please let me
know.
--
From: David
On Fri, Jan 03, 2014 at 01:21:18PM -0800, walt wrote:
> I'm so sorry Sarah, that was another mistake. The mistake is so stupid I'm
> not
> going to publish it here :(
>
> Once I finally ran the kernel with debugging actually compiled in, dmesg
> contains
> xhci debugging messages. Wow :)
>
>
On 01/03/2014 11:54 AM, Sarah Sharp wrote:
> On Fri, Jan 03, 2014 at 07:40:33AM -0800, walt wrote:
>> On 01/02/2014 11:15 AM, Sarah Sharp wrote:
>>> On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
> 3.12-stable review patch. If
On Fri, Jan 03, 2014 at 07:40:33AM -0800, walt wrote:
> On 01/02/2014 11:15 AM, Sarah Sharp wrote:
> > On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
> >> On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
> >>> 3.12-stable review patch. If anyone has any objections, please let me
> >>>
On 01/02/2014 11:15 AM, Sarah Sharp wrote:
> On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
>> On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
>>> 3.12-stable review patch. If anyone has any objections, please let me know.
>>>
>>> --
>>>
>>> From: David Laight
>>>
>>>
On 01/02/2014 11:15 AM, Sarah Sharp wrote:
On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
3.12-stable review patch. If anyone has any objections, please let me know.
--
From: David Laight david.lai...@aculab.com
On Fri, Jan 03, 2014 at 07:40:33AM -0800, walt wrote:
On 01/02/2014 11:15 AM, Sarah Sharp wrote:
On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
3.12-stable review patch. If anyone has any objections, please let me
know.
On 01/03/2014 11:54 AM, Sarah Sharp wrote:
On Fri, Jan 03, 2014 at 07:40:33AM -0800, walt wrote:
On 01/02/2014 11:15 AM, Sarah Sharp wrote:
On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
3.12-stable review patch. If anyone has any
On Fri, Jan 03, 2014 at 01:21:18PM -0800, walt wrote:
I'm so sorry Sarah, that was another mistake. The mistake is so stupid I'm
not
going to publish it here :(
Once I finally ran the kernel with debugging actually compiled in, dmesg
contains
xhci debugging messages. Wow :)
It's a
On Thu, Jan 02, 2014 at 04:01:29PM -0500, Mark Lord wrote:
> On 14-01-02 02:15 PM, Sarah Sharp wrote:
> > On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
> ..
> >> Unfortunately this patch causes a regression when copying large files to my
> >> outboard USB3 drive. (Nothing at all to do with
On Thu, 2014-01-02 at 16:01 -0500, Mark Lord wrote:
> On 14-01-02 02:15 PM, Sarah Sharp wrote:
> > On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
> ..
> >> Unfortunately this patch causes a regression when copying large files to my
> >> outboard USB3 drive. (Nothing at all to do with
On 14-01-02 02:15 PM, Sarah Sharp wrote:
> On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
..
>> Unfortunately this patch causes a regression when copying large files to my
>> outboard USB3 drive. (Nothing at all to do with networking.)
>>
>> When I try to copy a large (20GB) file to the
On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
> On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
> > 3.12-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: David Laight
> >
> > commit
On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
3.12-stable review patch. If anyone has any objections, please let me know.
--
From: David Laight david.lai...@aculab.com
commit
On 14-01-02 02:15 PM, Sarah Sharp wrote:
On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
..
Unfortunately this patch causes a regression when copying large files to my
outboard USB3 drive. (Nothing at all to do with networking.)
When I try to copy a large (20GB) file to the USB3 drive,
On Thu, 2014-01-02 at 16:01 -0500, Mark Lord wrote:
On 14-01-02 02:15 PM, Sarah Sharp wrote:
On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
..
Unfortunately this patch causes a regression when copying large files to my
outboard USB3 drive. (Nothing at all to do with networking.)
On Thu, Jan 02, 2014 at 04:01:29PM -0500, Mark Lord wrote:
On 14-01-02 02:15 PM, Sarah Sharp wrote:
On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
..
Unfortunately this patch causes a regression when copying large files to my
outboard USB3 drive. (Nothing at all to do with
On 13-12-31 03:40 PM, walt wrote:
> On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
>> 3.12-stable review patch. If anyone has any objections, please let me know.
>>
>> --
>>
>> From: David Laight
>>
>> commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e upstream.
>>
>> Section
On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
> 3.12-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: David Laight
>
> commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e upstream.
>
> Section 4.11.7.1 of rev 1.0 of the xhci
On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
3.12-stable review patch. If anyone has any objections, please let me know.
--
From: David Laight david.lai...@aculab.com
commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e upstream.
Section 4.11.7.1 of rev 1.0 of the
On 13-12-31 03:40 PM, walt wrote:
On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
3.12-stable review patch. If anyone has any objections, please let me know.
--
From: David Laight david.lai...@aculab.com
commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e upstream.
Section
96 matches
Mail list logo
