ernel.org>
> Subject: xHCI out of order events on BSD, was Re: xhci and other woes
>
> On Thu, Feb 06, 2014 at 11:30:29AM +0100, Hans Petter Selasky wrote:
>> On 02/04/14 20:10, Sarah Sharp wrote:
>>> And there's code in the xHCI driver to ignore the second successful
&
On Thu, Feb 06, 2014 at 11:30:29AM +0100, Hans Petter Selasky wrote:
> On 02/04/14 20:10, Sarah Sharp wrote:
> >And there's code in the xHCI driver to ignore the second successful
> >event. See ep->last_td_was_short. Yes, this is a slight race
> >condition, and we should wait for the successful e
ok so the nic died even via the hub now it looks like certain traffic does it.
reverting the fragment patch didnt help.
argh.
On Friday 07 February 2014 13:32:56 renev...@internode.on.net wrote:
> Ok it appears I was wrong about the NEC quirk.
>
>
> Here is what i'm seeing at the moment:
>
>
Ok it appears I was wrong about the NEC quirk.
Here is what i'm seeing at the moment:
The ax88179 is only working for me on the Renesas uPD720201 via a USB 3.0 HUB.
However for some reason once I use the hub I get :
xhci_hcd :02:00.0: WARN Successful completion on short TX: needs
XHCI_TRU
On Thu, Feb 06, 2014 at 07:42:33PM +1100, renev...@internode.on.net wrote:
> Hello guys,
>
> Currently i've done this in xhci-pci.c
>
> #define PCI_VENDOR_ID_RENESAS 0x1912
> #define PCI_DEVICE_ID_RENESAS_UPD720201 0x0014
>
>
> if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
>
On 02/04/14 20:10, Sarah Sharp wrote:
And there's code in the xHCI driver to ignore the second successful
event. See ep->last_td_was_short. Yes, this is a slight race
condition, and we should wait for the successful event. However, we
have not seen any issues with this race condition.
Hi,
S
From: Sarah> Sharp
> On Wed, Feb 05, 2014 at 09:44:20AM +, David Laight wrote:
> > 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
> > > >
Hello guys,
Currently i've done this in xhci-pci.c
#define PCI_VENDOR_ID_RENESAS 0x1912
#define PCI_DEVICE_ID_RENESAS_UPD720201 0x0014
if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
pdev->device == PCI_DEVICE_ID_RENESAS_UPD720201 &&
On Wed, Feb 05, 2014 at 09:44:20AM +, David Laight wrote:
> 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 th
Sarah Sharp wrote:
> Yes, this is a slight race condition, and we should wait for the
> successful event. However, we have not seen any issues with this
> race condition.
I'm glad that you say that having the race is wrong ("we should") and
I guess that "we should wait" for the sake of correctnes
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
It couldn't have been nomsi because I forgot to preface it with pci=
I also have the nic plugged in via a hub which I included in all my messing
around lol.
[ 96.210387] usb 9-4: Product: USB3.0 Hub
[ 96.210391] usb 9-4: Manufacturer: GenesysLogic
[ 96.213442] hub 9-4:1.0: USB hub found
[
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
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/interrupts it looks like everything that used to be
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
On 14-02-04 02:10 PM, Sarah Sharp wrote:
> On Mon, Feb 03, 2014 at 04:45:14PM +, David Laight wrote:
>
>> From the end of section 4.10.1.1 (Short transfers)
>> - If the Short Packet occurred while processing a Transfer TRB with only an
>> ISP flag set, then two events shall be generated for t
On Mon, Feb 03, 2014 at 04:45:14PM +, David Laight wrote:
> 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 probab
Downloaded and compiled the r8168 driver from the Realtek website.
Problem appears to be solved.
One other thing, off Asix's website the driver there for the ax88179 has two
extra module parameters for bulk transfers, one for buffer size the other for
timing. When I was playing around I did no
Bought a NEC/Renesas pD7020201 based pcie card today.
Ok so now I have a really strange problem if I load the r8169 realtek ethernet
module before xhci_hcd the Renesas controller gets a timeout on initialization
error.
If I load the xhci_hcd module before the r8169 module then my onboard ethe
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 transmits) fails generating some
> > 'TRB DMA ptr not part
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
> 'TRB DMA ptr not part of current TD' errors.
> I thi
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
One last thing.
With the VL800, the thing that crashed the system was traffic being
transmitted to a client wirelessly over a VPN with an MTU of 1300 I'm not sure
if it was ip fragments or something causing the issue or what but everything
else was pretty much ok in the end except for this, I
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.0 this issue. Perhaps this is BIOS
versi
24 matches
Mail list logo
