Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
On Sun, Aug 26, 2018 at 11:53 AM Denis wrote: > > After about a week of work axen0 has: > > Ierrs = 101 (patched by axen4.diff on 6.3 according to netstat -in) Thank you for reporting. I have to debug with privacy consideration. > > Denis > > On 8/18/2018 4:32 PM, sc.dy...@gmail.com wrote: > > Hi, > > > > On 2018/08/18 07:37, Denis wrote: > >> Hi, > >> > >> checksum err (pkt#1) appears in dmesg output only. > >> > >> Right now (after 43 hours of testing) there are 15 rows with checksum > >> err (pkt#1) message. > >> > >> Previously, that network segment was connected by em(4), fxp(4), xl(4) > >> drivers w/o any issues. So the error appears for axen(4) driver > >> exclusively. It seems axen(4) related issue. > > > > ierrs of netstat -in of these interfaces are 0? > > > > I added printf more informations about checksum error, > > and attached as axen4.diff. > > If you are interested in the packet body, you can see hexdump of > > the error packet by changing #if 0 to #if 1 in axen_rxeof(). > > Note that the hexdump includes MAC addresses and IP addresses. > > > > BTW original axen code leaks mbuf if checksum errors occurs. > > You can see mbuf usage is increasing when cksum error occur. > > This patch will fix that bug, too. > > > >> > >> Denis > >> > >> On 8/17/2018 6:26 PM, sc dying wrote: > >>> Hi, > >>> > >>> On 2018/08/17 07:40, Denis wrote: > Hi, > > 24 hour full load testing shows positive results. > >>> > >>> Good news. > >>> > > After axen3.diff has been implemented there is no TX/RX error present at > all. But 'checksum err (pkt#1)' appears repeatedly like this: > > ... > checksum err (pkt#1) > checksum err (pkt#1) > checksum err (pkt#1) > ... > > You're right DHCP client is working for axen0: > > # cat /etc/hostname.axen0 > dhcp lladdr yy.yy.yy.yy.yy > > What can cause 'checksum err (pkt#1)' for axen? > >>> > >>> It might be another bug of axen(4), or someone on your ethernet segment > >>> really sends bogus packets. > >>> In latter case I don't think axen should report each error to the console. > >>> > > Denis > > On 8/15/2018 2:29 AM, sc.dy...@gmail.com wrote: > > Hi, > > > > On 2018/08/14 08:19, Denis wrote: > >> I have 6.3 kernel compiled with option XHCI_debug and axen2.diff > >> implemented. > >> > >> I'm using lladdr option for /etc/hostname.axen0 to have the same IP > >> addr > >> each session for different Ehternet adapters. > >> > >> Here is debug output when axen is connected: > > > > Thank you for sending report. > > > > It looks someone (maybe DHCP) makes the interface down and up > > repeatedly. > > That causes TXERR (transaction error) on RX pipe. > > I guess there is something inconsistent between the state of xhci and > > the device. xhci spec 1.1 sec 4.3.5 requires the driver shall do > > set_config and configure endpoint. > > > > I added set_config part to axen2.diff and attached as axen3.diff. > > Can you try attached axen3.diff? > > > > Thanks. > > > >> > > >
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
On Sat, Aug 25, 2018 at 9:39 PM Remi Locherer wrote:
>
> On Fri, Aug 24, 2018 at 06:02:20AM +, sc.dy...@gmail.com wrote:
> > On 2018/08/19 09:40, Stefan Sperling wrote:
> > > On Sun, Aug 19, 2018 at 11:05:04AM +0200, Stefan Sperling wrote:
> > >> On Sun, Aug 19, 2018 at 09:56:33AM +0200, Remi Locherer wrote:
> > >>> It would help if you could send a clean version that applies to
> > >>> -current.
> > >>
> > >> One of the attachments was in fact clean but yes, this
> > >> thread has been much too noisy to follow easily.
> > >>
> > >> Try this.
> > >
> > > Unfortunately, while this diff does indeed work on xhci(4), I've just
> > > found that this diff breaks axen(4) attached to ehci(4) completely.
> > >
> > > I see several "axen0: rxeof: too short transfer" in dmesg and
> > > almost all packets are lost. Even my Ethernet switch gives up
> > > eventually and disables the port.
> > >
> > > So this diff is not ready to be committed.
> >
> > I didn't check if axen works on ehci.
> > On my ehci (intel PCH) that bug is reproduced, and
> > I found that it works on ehci with 16kB RX buffer.
> > I preserve the original bufsz decision code.
>
> I applied axen5.diff and xhci.diff and tested the resulting kernel on
> an old Samsung notebook that has ehci and xhci (demesg and usbdevs below).
>
> When the axen dongle is attached via xhci it gets link but dhclient
> never gets a lease. This works when attached via ehci. But after some
> light traffic (browsing with netsurf) the systme panics. Here the output
> from ddb (copied by hand):
Thank you for testing and reporting.
It might be a bad idea to modify xhci.c without a solid knowledge.
>
>
> kernel: page fault trap, code=0
> Stopped at memcpy+0x15:repe movsq (%rsi),%es:(rdi)
> ddb{1}> show panic
> kernel page fault
> uvm_fault(0xffdef19438, 0x0, 0, 1) -> e
> memcpy(79e3..) at memcpy+0x15
> end trace frame: 0x800032e06cd0, cound: 0
> ddb{1} trace
> memcpy(79e...) at memcpy+0x15
> ptcread(5b11cd.) at ptcread+0x1eb
> spec_read(70e.) at spec_read+0xab
> VOP_READ(4b037..) at VOP_RAED+0x49
> vn_read(af8b.) at dofilereadv+0xe0
> sys_read(9862) at sys_read+0x5c
> syscall(822b.) at syscall+0x32a
> Xsyscall(0,3,0,3,f,1954e...) at Xsyscall+0x128
> end of kernel
> end trace frame 0x7f7d3430, count: -9
> ddb{1}> mach ddb 0
> Stopped at x86_ipi_db+0x12: popq%r11
> ddb{0}> trace
> x86_ipi_db(5d...) at x86_ipi_db+0x12
> x86_ipi_handler() at x86_ipi_handler+0x80
> Xresume_lapic_ipi(9,ff.) at Xresume_lapic_ipi+0x23
> ___mp_lock(58ifaff) at ___mp_lock+0x68
> intr_handler(a26f9) at intr_handler+0x40
> Xintr_ioapic_edge12_untramp(6,fff...) at Xintr_ioapic_edge12_untramp+0x19f
> ___mp_lock(58faff...) at___mp_lock+0x68
> intr_handler(a26f9) at intr_handler+040
> Xintr_ioapic_edge25_untramp(0,3,..) at Xintr_ioapic_edge25_untramp+0x19f
> acpicpu_idle() at acpicpu_idle+0x166
> sched_idle(0) at sced_idle+0x245
> end trace frame: 0x0, count: -11
> ddb{0}
>
>
> This does not happen when running a snapshot kernel.
>
> dmesg + usbdevs -vvv
>
> OpenBSD 6.4-beta (GENERIC.MP) #0: Sat Aug 25 19:45:29 CEST 2018
> r...@530u.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8462659584 (8070MB)
> avail mem = 8196993024 (7817MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0840 (63 entries)
> bios0: vendor Phoenix Technologies Ltd. version "05XK" date 02/10/2012
> bios0: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG SSDT SSDT UEFI UEFI UEFI
> acpi0: wakeup devices P0P1(S4) GLAN(S4) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4)
> RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) PXSX(S4)
> RP07(S4) PXSX(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz, 1597.58 MHz, 06-2a-07
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz, 1895.69 MHz, 06-2a-07
> cpu1:
>
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
After about a week of work axen0 has: Ierrs = 101 (patched by axen4.diff on 6.3 according to netstat -in) Denis On 8/18/2018 4:32 PM, sc.dy...@gmail.com wrote: > Hi, > > On 2018/08/18 07:37, Denis wrote: >> Hi, >> >> checksum err (pkt#1) appears in dmesg output only. >> >> Right now (after 43 hours of testing) there are 15 rows with checksum >> err (pkt#1) message. >> >> Previously, that network segment was connected by em(4), fxp(4), xl(4) >> drivers w/o any issues. So the error appears for axen(4) driver >> exclusively. It seems axen(4) related issue. > > ierrs of netstat -in of these interfaces are 0? > > I added printf more informations about checksum error, > and attached as axen4.diff. > If you are interested in the packet body, you can see hexdump of > the error packet by changing #if 0 to #if 1 in axen_rxeof(). > Note that the hexdump includes MAC addresses and IP addresses. > > BTW original axen code leaks mbuf if checksum errors occurs. > You can see mbuf usage is increasing when cksum error occur. > This patch will fix that bug, too. > >> >> Denis >> >> On 8/17/2018 6:26 PM, sc dying wrote: >>> Hi, >>> >>> On 2018/08/17 07:40, Denis wrote: Hi, 24 hour full load testing shows positive results. >>> >>> Good news. >>> After axen3.diff has been implemented there is no TX/RX error present at all. But 'checksum err (pkt#1)' appears repeatedly like this: ... checksum err (pkt#1) checksum err (pkt#1) checksum err (pkt#1) ... You're right DHCP client is working for axen0: # cat /etc/hostname.axen0 dhcp lladdr yy.yy.yy.yy.yy What can cause 'checksum err (pkt#1)' for axen? >>> >>> It might be another bug of axen(4), or someone on your ethernet segment >>> really sends bogus packets. >>> In latter case I don't think axen should report each error to the console. >>> Denis On 8/15/2018 2:29 AM, sc.dy...@gmail.com wrote: > Hi, > > On 2018/08/14 08:19, Denis wrote: >> I have 6.3 kernel compiled with option XHCI_debug and axen2.diff >> implemented. >> >> I'm using lladdr option for /etc/hostname.axen0 to have the same IP addr >> each session for different Ehternet adapters. >> >> Here is debug output when axen is connected: > > Thank you for sending report. > > It looks someone (maybe DHCP) makes the interface down and up repeatedly. > That causes TXERR (transaction error) on RX pipe. > I guess there is something inconsistent between the state of xhci and > the device. xhci spec 1.1 sec 4.3.5 requires the driver shall do > set_config and configure endpoint. > > I added set_config part to axen2.diff and attached as axen3.diff. > Can you try attached axen3.diff? > > Thanks. > >> >
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
On Fri, Aug 24, 2018 at 06:02:20AM +, sc.dy...@gmail.com wrote:
> On 2018/08/19 09:40, Stefan Sperling wrote:
> > On Sun, Aug 19, 2018 at 11:05:04AM +0200, Stefan Sperling wrote:
> >> On Sun, Aug 19, 2018 at 09:56:33AM +0200, Remi Locherer wrote:
> >>> It would help if you could send a clean version that applies to -current.
> >>
> >> One of the attachments was in fact clean but yes, this
> >> thread has been much too noisy to follow easily.
> >>
> >> Try this.
> >
> > Unfortunately, while this diff does indeed work on xhci(4), I've just
> > found that this diff breaks axen(4) attached to ehci(4) completely.
> >
> > I see several "axen0: rxeof: too short transfer" in dmesg and
> > almost all packets are lost. Even my Ethernet switch gives up
> > eventually and disables the port.
> >
> > So this diff is not ready to be committed.
>
> I didn't check if axen works on ehci.
> On my ehci (intel PCH) that bug is reproduced, and
> I found that it works on ehci with 16kB RX buffer.
> I preserve the original bufsz decision code.
I applied axen5.diff and xhci.diff and tested the resulting kernel on
an old Samsung notebook that has ehci and xhci (demesg and usbdevs below).
When the axen dongle is attached via xhci it gets link but dhclient
never gets a lease. This works when attached via ehci. But after some
light traffic (browsing with netsurf) the systme panics. Here the output
from ddb (copied by hand):
kernel: page fault trap, code=0
Stopped at memcpy+0x15:repe movsq (%rsi),%es:(rdi)
ddb{1}> show panic
kernel page fault
uvm_fault(0xffdef19438, 0x0, 0, 1) -> e
memcpy(79e3..) at memcpy+0x15
end trace frame: 0x800032e06cd0, cound: 0
ddb{1} trace
memcpy(79e...) at memcpy+0x15
ptcread(5b11cd.) at ptcread+0x1eb
spec_read(70e.) at spec_read+0xab
VOP_READ(4b037..) at VOP_RAED+0x49
vn_read(af8b.) at dofilereadv+0xe0
sys_read(9862) at sys_read+0x5c
syscall(822b.) at syscall+0x32a
Xsyscall(0,3,0,3,f,1954e...) at Xsyscall+0x128
end of kernel
end trace frame 0x7f7d3430, count: -9
ddb{1}> mach ddb 0
Stopped at x86_ipi_db+0x12: popq%r11
ddb{0}> trace
x86_ipi_db(5d...) at x86_ipi_db+0x12
x86_ipi_handler() at x86_ipi_handler+0x80
Xresume_lapic_ipi(9,ff.) at Xresume_lapic_ipi+0x23
___mp_lock(58ifaff) at ___mp_lock+0x68
intr_handler(a26f9) at intr_handler+0x40
Xintr_ioapic_edge12_untramp(6,fff...) at Xintr_ioapic_edge12_untramp+0x19f
___mp_lock(58faff...) at___mp_lock+0x68
intr_handler(a26f9) at intr_handler+040
Xintr_ioapic_edge25_untramp(0,3,..) at Xintr_ioapic_edge25_untramp+0x19f
acpicpu_idle() at acpicpu_idle+0x166
sched_idle(0) at sced_idle+0x245
end trace frame: 0x0, count: -11
ddb{0}
This does not happen when running a snapshot kernel.
dmesg + usbdevs -vvv
OpenBSD 6.4-beta (GENERIC.MP) #0: Sat Aug 25 19:45:29 CEST 2018
r...@530u.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8462659584 (8070MB)
avail mem = 8196993024 (7817MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0840 (63 entries)
bios0: vendor Phoenix Technologies Ltd. version "05XK" date 02/10/2012
bios0: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG SSDT SSDT UEFI UEFI UEFI
acpi0: wakeup devices P0P1(S4) GLAN(S4) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4)
RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) PXSX(S4)
RP07(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz, 1597.58 MHz, 06-2a-07
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz, 1895.69 MHz, 06-2a-07
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 14 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
On 2018/08/19 09:40, Stefan Sperling wrote:
> On Sun, Aug 19, 2018 at 11:05:04AM +0200, Stefan Sperling wrote:
>> On Sun, Aug 19, 2018 at 09:56:33AM +0200, Remi Locherer wrote:
>>> It would help if you could send a clean version that applies to -current.
>>
>> One of the attachments was in fact clean but yes, this
>> thread has been much too noisy to follow easily.
>>
>> Try this.
>
> Unfortunately, while this diff does indeed work on xhci(4), I've just
> found that this diff breaks axen(4) attached to ehci(4) completely.
>
> I see several "axen0: rxeof: too short transfer" in dmesg and
> almost all packets are lost. Even my Ethernet switch gives up
> eventually and disables the port.
>
> So this diff is not ready to be committed.
I didn't check if axen works on ehci.
On my ehci (intel PCH) that bug is reproduced, and
I found that it works on ehci with 16kB RX buffer.
I preserve the original bufsz decision code.
- rxeof: Fix mbuf leak if checksum errors are detected.
- rxeof: Avoid loop to extract packets if pkt_count is 0.
- rxeof: Add more sanity checks.
- rxeof: Increament if_ierror in some error paths.
- qctrl: Apply queuing control parameters from FreeBSD axge(4).
- qctrl: Set qctrl in miireg_statchg dynamically, not in ax88179_init.
- init: Fix dhclient failure on xhci by calling set_config in init.
--- sys/dev/usb/if_axen.c.orig Wed Aug 8 16:30:40 2018
+++ sys/dev/usb/if_axen.c Wed Aug 22 12:38:18 2018
@@ -121,6 +121,13 @@ void axen_unlock_mii(struct axen_softc *sc);
void axen_ax88179_init(struct axen_softc *);
+struct axen_qctrl axen_bulk_size[] = {
+ { 7, 0x4f, 0x00, 0x12, 0xff },
+ { 7, 0x20, 0x03, 0x16, 0xff },
+ { 7, 0xae, 0x07, 0x18, 0xff },
+ { 7, 0xcc, 0x4c, 0x18, 0x08 }
+};
+
/* Get exclusive access to the MII registers */
void
axen_lock_mii(struct axen_softc *sc)
@@ -238,6 +245,8 @@ axen_miibus_statchg(struct device *dev)
int err;
uint16_tval;
uWord wval;
+ uint8_t linkstat = 0;
+ int qctrl;
ifp = GET_IFP(sc);
if (mii == NULL || ifp == NULL ||
@@ -265,27 +274,49 @@ axen_miibus_statchg(struct device *dev)
return;
val = 0;
- if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0)
+ if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0) {
val |= AXEN_MEDIUM_FDX;
+ if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_TXPAUSE) != 0)
+ val |= AXEN_MEDIUM_TXFLOW_CTRL_EN;
+ if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_RXPAUSE) != 0)
+ val |= AXEN_MEDIUM_RXFLOW_CTRL_EN;
+ }
- val |= (AXEN_MEDIUM_RECV_EN | AXEN_MEDIUM_ALWAYS_ONE);
- val |= (AXEN_MEDIUM_RXFLOW_CTRL_EN | AXEN_MEDIUM_TXFLOW_CTRL_EN);
+ val |= AXEN_MEDIUM_RECV_EN;
+ /* bulkin queue setting */
+ axen_lock_mii(sc);
+ axen_cmd(sc, AXEN_CMD_MAC_READ, 1, AXEN_USB_UPLINK, );
+ axen_unlock_mii(sc);
+
switch (IFM_SUBTYPE(mii->mii_media_active)) {
case IFM_1000_T:
val |= AXEN_MEDIUM_GIGA | AXEN_MEDIUM_EN_125MHZ;
+ if (linkstat & AXEN_USB_SS)
+ qctrl = 0;
+ else if (linkstat & AXEN_USB_HS)
+ qctrl = 1;
+ else
+ qctrl = 3;
break;
case IFM_100_TX:
val |= AXEN_MEDIUM_PS;
+ if (linkstat & (AXEN_USB_SS | AXEN_USB_HS))
+ qctrl = 2;
+ else
+ qctrl = 3;
break;
case IFM_10_T:
- /* doesn't need to be handled */
+ default:
+ qctrl = 3;
break;
}
DPRINTF(("axen_miibus_statchg: val=0x%x\n", val));
USETW(wval, val);
axen_lock_mii(sc);
+ axen_cmd(sc, AXEN_CMD_MAC_SET_RXSR, 5, AXEN_RX_BULKIN_QCTRL,
+ _bulk_size[qctrl]);
err = axen_cmd(sc, AXEN_CMD_MAC_WRITE2, 2, AXEN_MEDIUM_STATUS, );
axen_unlock_mii(sc);
if (err) {
@@ -408,7 +439,6 @@ axen_ax88179_init(struct axen_softc *sc)
uWord wval;
uByte val;
u_int16_t ctl, temp;
- struct axen_qctrl qctrl;
axen_lock_mii(sc);
@@ -471,27 +501,12 @@ axen_ax88179_init(struct axen_softc *sc)
switch (val) {
case AXEN_USB_FS:
DPRINTF(("uplink: USB1.1\n"));
- qctrl.ctrl = 0x07;
- qctrl.timer_low = 0xcc;
- qctrl.timer_high= 0x4c;
- qctrl.bufsize = AXEN_BUFSZ_LS - 1;
- qctrl.ifg = 0x08;
break;
case AXEN_USB_HS:
DPRINTF(("uplink: USB2.0\n"));
- qctrl.ctrl = 0x07;
- qctrl.timer_low = 0x02;
-
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
On Sun, Aug 19, 2018 at 11:40:50AM +0200, Stefan Sperling wrote: > On Sun, Aug 19, 2018 at 11:05:04AM +0200, Stefan Sperling wrote: > > On Sun, Aug 19, 2018 at 09:56:33AM +0200, Remi Locherer wrote: > > > It would help if you could send a clean version that applies to -current. > > > > One of the attachments was in fact clean but yes, this > > thread has been much too noisy to follow easily. > > > > Try this. > > Unfortunately, while this diff does indeed work on xhci(4), I've just > found that this diff breaks axen(4) attached to ehci(4) completely. > > I see several "axen0: rxeof: too short transfer" in dmesg and > almost all packets are lost. Even my Ethernet switch gives up > eventually and disables the port. > > So this diff is not ready to be committed. By now I verified that this is an improvement on xhci. Before I could panic my machine by unplugging axen while transfering date. Also without this diff after some time axen got "stuck" and I needed to unplug (dangerous) to get it working again. I'll prepare machine with ehci to be able to test the next diff. ;-) Remi
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
On 2018/08/18 08:38, Stefan Sperling wrote: > Thank you for taking care of axen(4). > The problems with this driver have been known for some time. > > On Tue, Aug 07, 2018 at 02:04:24PM +, sc.dy...@gmail.com wrote: >> - header: fix comments >> - header: fix unused L3 type mask definition >> - rxeof: Avoid allocating mbuf if checksum errors are detected. >> - rxeof: Avoid loop to extract packets if pkt_count is 0. >> - rxeof: Add more sanity checks. >> - rxeof: Increament if_ierror in some error paths. >> - qctrl: Apply queuing control parameters from FreeBSD axge(4). >> - qctrl: Set qctrl in miireg_statchg dynamically, not statically. >> - Use DMA buffer aligned at 64KB boundary to avoid xhci bug. > > You're actually switching to a 64KB buffer size as well, not only to > 64KB alignment. That is a relatively large size. The previous code > was using 8KB, 16KB, and 24KB buffers. Do I understand correctly > that the qctrl configuration allows hardware to provide only up > to 0x18*1024 = 24KB bytes of packet data per Rx interrupt? Currently patched axen uses 64kB RX buffer. If axen works with 24kB RX buffer, 24kB should be used. The original code of FreeBSD axge used 24kB buffer but has incleased to 64kB buf. I don't know why. log of rev 268582 says: > - The maximum RX buffer was incorrectly set. Increase it to 64K for > now, until the exact limit is understood. > > Regardless, in my opinion your diff improves this driver which > has not seen any regular maintainance in a long time. > If another developer (remi? mlarkin?) provides an OK I will commit it. > The patch around axen_alloc_buffer() is avoid the xhci bug. I don't recommand to commit this part into the tree. The xhci.c should be fixed first.
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
On Sun, Aug 19, 2018 at 11:05:04AM +0200, Stefan Sperling wrote: > On Sun, Aug 19, 2018 at 09:56:33AM +0200, Remi Locherer wrote: > > It would help if you could send a clean version that applies to -current. > > One of the attachments was in fact clean but yes, this > thread has been much too noisy to follow easily. > > Try this. Unfortunately, while this diff does indeed work on xhci(4), I've just found that this diff breaks axen(4) attached to ehci(4) completely. I see several "axen0: rxeof: too short transfer" in dmesg and almost all packets are lost. Even my Ethernet switch gives up eventually and disables the port. So this diff is not ready to be committed.
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
On Sun, Aug 19, 2018 at 09:56:33AM +0200, Remi Locherer wrote:
> It would help if you could send a clean version that applies to -current.
One of the attachments was in fact clean but yes, this
thread has been much too noisy to follow easily.
Try this.
Index: if_axen.c
===
RCS file: /cvs/src/sys/dev/usb/if_axen.c,v
retrieving revision 1.25
diff -u -p -r1.25 if_axen.c
--- if_axen.c 12 Jun 2018 06:59:27 - 1.25
+++ if_axen.c 18 Aug 2018 08:06:02 -
@@ -53,6 +53,7 @@
#include
#include
#include
+#include
#include
@@ -121,6 +122,13 @@ void axen_unlock_mii(struct axen_softc *
void axen_ax88179_init(struct axen_softc *);
+struct axen_qctrl axen_bulk_size[] = {
+ { 7, 0x4f, 0x00, 0x12, 0xff },
+ { 7, 0x20, 0x03, 0x16, 0xff },
+ { 7, 0xae, 0x07, 0x18, 0xff },
+ { 7, 0xcc, 0x4c, 0x18, 0x08 }
+};
+
/* Get exclusive access to the MII registers */
void
axen_lock_mii(struct axen_softc *sc)
@@ -238,6 +246,8 @@ axen_miibus_statchg(struct device *dev)
int err;
uint16_tval;
uWord wval;
+ uint8_t linkstat = 0;
+ int qctrl;
ifp = GET_IFP(sc);
if (mii == NULL || ifp == NULL ||
@@ -265,27 +275,49 @@ axen_miibus_statchg(struct device *dev)
return;
val = 0;
- if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0)
+ if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0) {
val |= AXEN_MEDIUM_FDX;
+ if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_TXPAUSE) != 0)
+ val |= AXEN_MEDIUM_TXFLOW_CTRL_EN;
+ if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_RXPAUSE) != 0)
+ val |= AXEN_MEDIUM_RXFLOW_CTRL_EN;
+ }
- val |= (AXEN_MEDIUM_RECV_EN | AXEN_MEDIUM_ALWAYS_ONE);
- val |= (AXEN_MEDIUM_RXFLOW_CTRL_EN | AXEN_MEDIUM_TXFLOW_CTRL_EN);
+ val |= AXEN_MEDIUM_RECV_EN;
+
+ /* bulkin queue setting */
+ axen_lock_mii(sc);
+ axen_cmd(sc, AXEN_CMD_MAC_READ, 1, AXEN_USB_UPLINK, );
+ axen_unlock_mii(sc);
switch (IFM_SUBTYPE(mii->mii_media_active)) {
case IFM_1000_T:
val |= AXEN_MEDIUM_GIGA | AXEN_MEDIUM_EN_125MHZ;
+ if (linkstat & AXEN_USB_SS)
+ qctrl = 0;
+ else if (linkstat & AXEN_USB_HS)
+ qctrl = 1;
+ else
+ qctrl = 3;
break;
case IFM_100_TX:
val |= AXEN_MEDIUM_PS;
+ if (linkstat & (AXEN_USB_SS | AXEN_USB_HS))
+ qctrl = 2;
+ else
+ qctrl = 3;
break;
case IFM_10_T:
- /* doesn't need to be handled */
+ default:
+ qctrl = 3;
break;
}
DPRINTF(("axen_miibus_statchg: val=0x%x\n", val));
USETW(wval, val);
axen_lock_mii(sc);
+ axen_cmd(sc, AXEN_CMD_MAC_SET_RXSR, 5, AXEN_RX_BULKIN_QCTRL,
+ _bulk_size[qctrl]);
err = axen_cmd(sc, AXEN_CMD_MAC_WRITE2, 2, AXEN_MEDIUM_STATUS, );
axen_unlock_mii(sc);
if (err) {
@@ -408,7 +440,6 @@ axen_ax88179_init(struct axen_softc *sc)
uWord wval;
uByte val;
u_int16_t ctl, temp;
- struct axen_qctrl qctrl;
axen_lock_mii(sc);
@@ -471,27 +502,12 @@ axen_ax88179_init(struct axen_softc *sc)
switch (val) {
case AXEN_USB_FS:
DPRINTF(("uplink: USB1.1\n"));
- qctrl.ctrl = 0x07;
- qctrl.timer_low = 0xcc;
- qctrl.timer_high= 0x4c;
- qctrl.bufsize = AXEN_BUFSZ_LS - 1;
- qctrl.ifg = 0x08;
break;
case AXEN_USB_HS:
DPRINTF(("uplink: USB2.0\n"));
- qctrl.ctrl = 0x07;
- qctrl.timer_low = 0x02;
- qctrl.timer_high= 0xa0;
- qctrl.bufsize = AXEN_BUFSZ_HS - 1;
- qctrl.ifg = 0xff;
break;
case AXEN_USB_SS:
DPRINTF(("uplink: USB3.0\n"));
- qctrl.ctrl = 0x07;
- qctrl.timer_low = 0x4f;
- qctrl.timer_high= 0x00;
- qctrl.bufsize = AXEN_BUFSZ_SS - 1;
- qctrl.ifg = 0xff;
break;
default:
printf("%s: unknown uplink bus:0x%02x\n",
@@ -499,7 +515,6 @@ axen_ax88179_init(struct axen_softc *sc)
axen_unlock_mii(sc);
return;
}
- axen_cmd(sc, AXEN_CMD_MAC_SET_RXSR, 5, AXEN_RX_BULKIN_QCTRL, );
/* Set MAC address. */
axen_cmd(sc, AXEN_CMD_MAC_WRITE_ETHER, ETHER_ADDR_LEN,
@@ -622,22 +637,8 @@
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
For last 14 hours there is no any checksum err (pkt#1) according to netstat -in. On 8/18/2018 4:32 PM, sc.dy...@gmail.com wrote: > Hi, > > On 2018/08/18 07:37, Denis wrote: >> Hi, >> >> checksum err (pkt#1) appears in dmesg output only. >> >> Right now (after 43 hours of testing) there are 15 rows with checksum >> err (pkt#1) message. >> >> Previously, that network segment was connected by em(4), fxp(4), xl(4) >> drivers w/o any issues. So the error appears for axen(4) driver >> exclusively. It seems axen(4) related issue. > > ierrs of netstat -in of these interfaces are 0? > > I added printf more informations about checksum error, > and attached as axen4.diff. > If you are interested in the packet body, you can see hexdump of > the error packet by changing #if 0 to #if 1 in axen_rxeof(). > Note that the hexdump includes MAC addresses and IP addresses. > > BTW original axen code leaks mbuf if checksum errors occurs. > You can see mbuf usage is increasing when cksum error occur. > This patch will fix that bug, too. > >> >> Denis >> >> On 8/17/2018 6:26 PM, sc dying wrote: >>> Hi, >>> >>> On 2018/08/17 07:40, Denis wrote: Hi, 24 hour full load testing shows positive results. >>> >>> Good news. >>> After axen3.diff has been implemented there is no TX/RX error present at all. But 'checksum err (pkt#1)' appears repeatedly like this: ... checksum err (pkt#1) checksum err (pkt#1) checksum err (pkt#1) ... You're right DHCP client is working for axen0: # cat /etc/hostname.axen0 dhcp lladdr yy.yy.yy.yy.yy What can cause 'checksum err (pkt#1)' for axen? >>> >>> It might be another bug of axen(4), or someone on your ethernet segment >>> really sends bogus packets. >>> In latter case I don't think axen should report each error to the console. >>> Denis On 8/15/2018 2:29 AM, sc.dy...@gmail.com wrote: > Hi, > > On 2018/08/14 08:19, Denis wrote: >> I have 6.3 kernel compiled with option XHCI_debug and axen2.diff >> implemented. >> >> I'm using lladdr option for /etc/hostname.axen0 to have the same IP addr >> each session for different Ehternet adapters. >> >> Here is debug output when axen is connected: > > Thank you for sending report. > > It looks someone (maybe DHCP) makes the interface down and up repeatedly. > That causes TXERR (transaction error) on RX pipe. > I guess there is something inconsistent between the state of xhci and > the device. xhci spec 1.1 sec 4.3.5 requires the driver shall do > set_config and configure endpoint. > > I added set_config part to axen2.diff and attached as axen3.diff. > Can you try attached axen3.diff? > > Thanks. > >> >
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
On Sat, Aug 18, 2018 at 10:38:36AM +0200, Stefan Sperling wrote:
> Thank you for taking care of axen(4).
> The problems with this driver have been known for some time.
>
> On Tue, Aug 07, 2018 at 02:04:24PM +, sc.dy...@gmail.com wrote:
> > - header: fix comments
> > - header: fix unused L3 type mask definition
> > - rxeof: Avoid allocating mbuf if checksum errors are detected.
> > - rxeof: Avoid loop to extract packets if pkt_count is 0.
> > - rxeof: Add more sanity checks.
> > - rxeof: Increament if_ierror in some error paths.
> > - qctrl: Apply queuing control parameters from FreeBSD axge(4).
> > - qctrl: Set qctrl in miireg_statchg dynamically, not statically.
> > - Use DMA buffer aligned at 64KB boundary to avoid xhci bug.
>
> You're actually switching to a 64KB buffer size as well, not only to
> 64KB alignment. That is a relatively large size. The previous code
> was using 8KB, 16KB, and 24KB buffers. Do I understand correctly
> that the qctrl configuration allows hardware to provide only up
> to 0x18*1024 = 24KB bytes of packet data per Rx interrupt?
>
> Regardless, in my opinion your diff improves this driver which
> has not seen any regular maintainance in a long time.
> If another developer (remi? mlarkin?) provides an OK I will commit it.
>
I wanted to test this. Unfortunately the axen4.diff does not apply
to my -current tree. Is it because of the white space issue mentioned
in the thread? Or do I need to first apply one of the other patches?
It would help if you could send a clean version that applies to -current.
Thank you for looking at improving axen(4)!
Remi
> > --- sys/dev/usb/if_axenreg.hFri Sep 16 22:17:07 2016
> > +++ sys/dev/usb/if_axenreg.hMon Jun 19 10:54:28 2017
> > @@ -26,8 +26,8 @@
> > * || ++-L3_type (1:ipv4, 0/2:ipv6)
> > *pkt_len(13) || ||+ ++-L4_type(0: icmp, 1: UDP, 4: TCP)
> > * |765|43210 76543210|7654 3210 7654 3210|
> > - * ||+-crc_err |+-L4_err |+-L4_CSUM_ERR
> > - * |+-mii_err +--L3_err +--L3_CSUM_ERR
> > + * ||+-crc_err |+-L4_err |+-L4_CSUM_ERR
> > + * |+-mii_err+--L3_err +--L3_CSUM_ERR
> > * +-drop_err
> > *
> > * ex) pkt_hdr 0x00680820
> > @@ -70,7 +70,7 @@
> > #define AXEN_RXHDR_L4_TYPE_TCP 0x4
> >
> > /* L3 packet type (2bit) */
> > -#define AXEN_RXHDR_L3_TYPE_MASK0x0600
> > +#define AXEN_RXHDR_L3_TYPE_MASK0x0060
> > #define AXEN_RXHDR_L3_TYPE_OFFSET 5
> > #define AXEN_RXHDR_L3_TYPE_UNDEF 0x0
> > #define AXEN_RXHDR_L3_TYPE_IPV4 0x1
> > --- sys/dev/usb/if_axen.c.orig Tue Jun 12 15:36:59 2018
> > +++ sys/dev/usb/if_axen.c Sun Jul 29 01:53:43 2018
> > @@ -53,6 +53,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> >
> > @@ -121,6 +122,13 @@ void axen_unlock_mii(struct axen_softc *sc);
> >
> > void axen_ax88179_init(struct axen_softc *);
> >
> > +struct axen_qctrl axen_bulk_size[] = {
> > + { 7, 0x4f, 0x00, 0x12, 0xff },
> > + { 7, 0x20, 0x03, 0x16, 0xff },
> > + { 7, 0xae, 0x07, 0x18, 0xff },
> > + { 7, 0xcc, 0x4c, 0x18, 0x08 }
> > +};
> > +
> > /* Get exclusive access to the MII registers */
> > void
> > axen_lock_mii(struct axen_softc *sc)
> > @@ -238,6 +246,8 @@ axen_miibus_statchg(struct device *dev)
> > int err;
> > uint16_tval;
> > uWord wval;
> > + uint8_t linkstat = 0;
> > + int qctrl;
> >
> > ifp = GET_IFP(sc);
> > if (mii == NULL || ifp == NULL ||
> > @@ -265,27 +275,49 @@ axen_miibus_statchg(struct device *dev)
> > return;
> >
> > val = 0;
> > - if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0)
> > + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0) {
> > val |= AXEN_MEDIUM_FDX;
> > + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_TXPAUSE) != 0)
> > + val |= AXEN_MEDIUM_TXFLOW_CTRL_EN;
> > + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_RXPAUSE) != 0)
> > + val |= AXEN_MEDIUM_RXFLOW_CTRL_EN;
> > + }
> >
> > - val |= (AXEN_MEDIUM_RECV_EN | AXEN_MEDIUM_ALWAYS_ONE);
> > - val |= (AXEN_MEDIUM_RXFLOW_CTRL_EN | AXEN_MEDIUM_TXFLOW_CTRL_EN);
> > + val |= AXEN_MEDIUM_RECV_EN;
> >
> > + /* bulkin queue setting */
> > + axen_lock_mii(sc);
> > + axen_cmd(sc, AXEN_CMD_MAC_READ, 1, AXEN_USB_UPLINK, );
> > + axen_unlock_mii(sc);
> > +
> > switch (IFM_SUBTYPE(mii->mii_media_active)) {
> > case IFM_1000_T:
> > val |= AXEN_MEDIUM_GIGA | AXEN_MEDIUM_EN_125MHZ;
> > + if (linkstat & AXEN_USB_SS)
> > + qctrl = 0;
> > + else if (linkstat & AXEN_USB_HS)
> > + qctrl = 1;
> > + else
> > + qctrl = 3;
> > break;
> > case IFM_100_TX:
> > val |=
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
Yes, netstat -in on em(4), fxp(4), xl(4) Ierrs=0 / Oerrs=0 for months. axen4.diff has been applied. Testing. On 8/18/2018 4:32 PM, sc.dy...@gmail.com wrote: > Hi, > > On 2018/08/18 07:37, Denis wrote: >> Hi, >> >> checksum err (pkt#1) appears in dmesg output only. >> >> Right now (after 43 hours of testing) there are 15 rows with checksum >> err (pkt#1) message. >> >> Previously, that network segment was connected by em(4), fxp(4), xl(4) >> drivers w/o any issues. So the error appears for axen(4) driver >> exclusively. It seems axen(4) related issue. > > ierrs of netstat -in of these interfaces are 0? > > I added printf more informations about checksum error, > and attached as axen4.diff. > If you are interested in the packet body, you can see hexdump of > the error packet by changing #if 0 to #if 1 in axen_rxeof(). > Note that the hexdump includes MAC addresses and IP addresses. > > BTW original axen code leaks mbuf if checksum errors occurs. > You can see mbuf usage is increasing when cksum error occur. > This patch will fix that bug, too. > >> >> Denis >> >> On 8/17/2018 6:26 PM, sc dying wrote: >>> Hi, >>> >>> On 2018/08/17 07:40, Denis wrote: Hi, 24 hour full load testing shows positive results. >>> >>> Good news. >>> After axen3.diff has been implemented there is no TX/RX error present at all. But 'checksum err (pkt#1)' appears repeatedly like this: ... checksum err (pkt#1) checksum err (pkt#1) checksum err (pkt#1) ... You're right DHCP client is working for axen0: # cat /etc/hostname.axen0 dhcp lladdr yy.yy.yy.yy.yy What can cause 'checksum err (pkt#1)' for axen? >>> >>> It might be another bug of axen(4), or someone on your ethernet segment >>> really sends bogus packets. >>> In latter case I don't think axen should report each error to the console. >>> Denis On 8/15/2018 2:29 AM, sc.dy...@gmail.com wrote: > Hi, > > On 2018/08/14 08:19, Denis wrote: >> I have 6.3 kernel compiled with option XHCI_debug and axen2.diff >> implemented. >> >> I'm using lladdr option for /etc/hostname.axen0 to have the same IP addr >> each session for different Ehternet adapters. >> >> Here is debug output when axen is connected: > > Thank you for sending report. > > It looks someone (maybe DHCP) makes the interface down and up repeatedly. > That causes TXERR (transaction error) on RX pipe. > I guess there is something inconsistent between the state of xhci and > the device. xhci spec 1.1 sec 4.3.5 requires the driver shall do > set_config and configure endpoint. > > I added set_config part to axen2.diff and attached as axen3.diff. > Can you try attached axen3.diff? > > Thanks. > >> >
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
Hi,
On 2018/08/18 07:37, Denis wrote:
> Hi,
>
> checksum err (pkt#1) appears in dmesg output only.
>
> Right now (after 43 hours of testing) there are 15 rows with checksum
> err (pkt#1) message.
>
> Previously, that network segment was connected by em(4), fxp(4), xl(4)
> drivers w/o any issues. So the error appears for axen(4) driver
> exclusively. It seems axen(4) related issue.
ierrs of netstat -in of these interfaces are 0?
I added printf more informations about checksum error,
and attached as axen4.diff.
If you are interested in the packet body, you can see hexdump of
the error packet by changing #if 0 to #if 1 in axen_rxeof().
Note that the hexdump includes MAC addresses and IP addresses.
BTW original axen code leaks mbuf if checksum errors occurs.
You can see mbuf usage is increasing when cksum error occur.
This patch will fix that bug, too.
>
> Denis
>
> On 8/17/2018 6:26 PM, sc dying wrote:
>> Hi,
>>
>> On 2018/08/17 07:40, Denis wrote:
>>> Hi,
>>>
>>> 24 hour full load testing shows positive results.
>>
>> Good news.
>>
>>>
>>> After axen3.diff has been implemented there is no TX/RX error present at
>>> all. But 'checksum err (pkt#1)' appears repeatedly like this:
>>>
>>> ...
>>> checksum err (pkt#1)
>>> checksum err (pkt#1)
>>> checksum err (pkt#1)
>>> ...
>>>
>>> You're right DHCP client is working for axen0:
>>>
>>> # cat /etc/hostname.axen0
>>> dhcp lladdr yy.yy.yy.yy.yy
>>>
>>> What can cause 'checksum err (pkt#1)' for axen?
>>
>> It might be another bug of axen(4), or someone on your ethernet segment
>> really sends bogus packets.
>> In latter case I don't think axen should report each error to the console.
>>
>>>
>>> Denis
>>>
>>> On 8/15/2018 2:29 AM, sc.dy...@gmail.com wrote:
Hi,
On 2018/08/14 08:19, Denis wrote:
> I have 6.3 kernel compiled with option XHCI_debug and axen2.diff
> implemented.
>
> I'm using lladdr option for /etc/hostname.axen0 to have the same IP addr
> each session for different Ehternet adapters.
>
> Here is debug output when axen is connected:
Thank you for sending report.
It looks someone (maybe DHCP) makes the interface down and up repeatedly.
That causes TXERR (transaction error) on RX pipe.
I guess there is something inconsistent between the state of xhci and
the device. xhci spec 1.1 sec 4.3.5 requires the driver shall do
set_config and configure endpoint.
I added set_config part to axen2.diff and attached as axen3.diff.
Can you try attached axen3.diff?
Thanks.
>
--- sys/dev/usb/if_axen.c.orig Sun Jan 22 10:17:39 2017
+++ sys/dev/usb/if_axen.c Sat Aug 18 12:16:25 2018
@@ -53,6 +53,7 @@
#include
#include
#include
+#include
#include
@@ -121,6 +122,13 @@ void axen_unlock_mii(struct axen_softc *sc);
void axen_ax88179_init(struct axen_softc *);
+struct axen_qctrl axen_bulk_size[] = {
+ { 7, 0x4f, 0x00, 0x12, 0xff },
+ { 7, 0x20, 0x03, 0x16, 0xff },
+ { 7, 0xae, 0x07, 0x18, 0xff },
+ { 7, 0xcc, 0x4c, 0x18, 0x08 }
+};
+
/* Get exclusive access to the MII registers */
void
axen_lock_mii(struct axen_softc *sc)
@@ -238,6 +246,8 @@ axen_miibus_statchg(struct device *dev)
int err;
uint16_tval;
uWord wval;
+ uint8_t linkstat = 0;
+ int qctrl;
ifp = GET_IFP(sc);
if (mii == NULL || ifp == NULL ||
@@ -265,27 +275,49 @@ axen_miibus_statchg(struct device *dev)
return;
val = 0;
- if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0)
+ if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0) {
val |= AXEN_MEDIUM_FDX;
+ if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_TXPAUSE) != 0)
+ val |= AXEN_MEDIUM_TXFLOW_CTRL_EN;
+ if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_RXPAUSE) != 0)
+ val |= AXEN_MEDIUM_RXFLOW_CTRL_EN;
+ }
- val |= (AXEN_MEDIUM_RECV_EN | AXEN_MEDIUM_ALWAYS_ONE);
- val |= (AXEN_MEDIUM_RXFLOW_CTRL_EN | AXEN_MEDIUM_TXFLOW_CTRL_EN);
+ val |= AXEN_MEDIUM_RECV_EN;
+ /* bulkin queue setting */
+ axen_lock_mii(sc);
+ axen_cmd(sc, AXEN_CMD_MAC_READ, 1, AXEN_USB_UPLINK, );
+ axen_unlock_mii(sc);
+
switch (IFM_SUBTYPE(mii->mii_media_active)) {
case IFM_1000_T:
val |= AXEN_MEDIUM_GIGA | AXEN_MEDIUM_EN_125MHZ;
+ if (linkstat & AXEN_USB_SS)
+ qctrl = 0;
+ else if (linkstat & AXEN_USB_HS)
+ qctrl = 1;
+ else
+ qctrl = 3;
break;
case IFM_100_TX:
val |= AXEN_MEDIUM_PS;
+ if (linkstat & (AXEN_USB_SS | AXEN_USB_HS))
+ qctrl = 2;
+ else
+
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
Thank you for taking care of axen(4).
The problems with this driver have been known for some time.
On Tue, Aug 07, 2018 at 02:04:24PM +, sc.dy...@gmail.com wrote:
> - header: fix comments
> - header: fix unused L3 type mask definition
> - rxeof: Avoid allocating mbuf if checksum errors are detected.
> - rxeof: Avoid loop to extract packets if pkt_count is 0.
> - rxeof: Add more sanity checks.
> - rxeof: Increament if_ierror in some error paths.
> - qctrl: Apply queuing control parameters from FreeBSD axge(4).
> - qctrl: Set qctrl in miireg_statchg dynamically, not statically.
> - Use DMA buffer aligned at 64KB boundary to avoid xhci bug.
You're actually switching to a 64KB buffer size as well, not only to
64KB alignment. That is a relatively large size. The previous code
was using 8KB, 16KB, and 24KB buffers. Do I understand correctly
that the qctrl configuration allows hardware to provide only up
to 0x18*1024 = 24KB bytes of packet data per Rx interrupt?
Regardless, in my opinion your diff improves this driver which
has not seen any regular maintainance in a long time.
If another developer (remi? mlarkin?) provides an OK I will commit it.
> --- sys/dev/usb/if_axenreg.h Fri Sep 16 22:17:07 2016
> +++ sys/dev/usb/if_axenreg.h Mon Jun 19 10:54:28 2017
> @@ -26,8 +26,8 @@
> * || ++-L3_type (1:ipv4, 0/2:ipv6)
> *pkt_len(13) || ||+ ++-L4_type(0: icmp, 1: UDP, 4: TCP)
> * |765|43210 76543210|7654 3210 7654 3210|
> - * ||+-crc_err |+-L4_err |+-L4_CSUM_ERR
> - * |+-mii_err +--L3_err +--L3_CSUM_ERR
> + * ||+-crc_err |+-L4_err |+-L4_CSUM_ERR
> + * |+-mii_err+--L3_err +--L3_CSUM_ERR
> * +-drop_err
> *
> * ex) pkt_hdr 0x00680820
> @@ -70,7 +70,7 @@
> #define AXEN_RXHDR_L4_TYPE_TCP 0x4
>
> /* L3 packet type (2bit) */
> -#define AXEN_RXHDR_L3_TYPE_MASK 0x0600
> +#define AXEN_RXHDR_L3_TYPE_MASK 0x0060
> #define AXEN_RXHDR_L3_TYPE_OFFSET5
> #define AXEN_RXHDR_L3_TYPE_UNDEF 0x0
> #define AXEN_RXHDR_L3_TYPE_IPV40x1
> --- sys/dev/usb/if_axen.c.origTue Jun 12 15:36:59 2018
> +++ sys/dev/usb/if_axen.c Sun Jul 29 01:53:43 2018
> @@ -53,6 +53,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -121,6 +122,13 @@ void axen_unlock_mii(struct axen_softc *sc);
>
> void axen_ax88179_init(struct axen_softc *);
>
> +struct axen_qctrl axen_bulk_size[] = {
> + { 7, 0x4f, 0x00, 0x12, 0xff },
> + { 7, 0x20, 0x03, 0x16, 0xff },
> + { 7, 0xae, 0x07, 0x18, 0xff },
> + { 7, 0xcc, 0x4c, 0x18, 0x08 }
> +};
> +
> /* Get exclusive access to the MII registers */
> void
> axen_lock_mii(struct axen_softc *sc)
> @@ -238,6 +246,8 @@ axen_miibus_statchg(struct device *dev)
> int err;
> uint16_tval;
> uWord wval;
> + uint8_t linkstat = 0;
> + int qctrl;
>
> ifp = GET_IFP(sc);
> if (mii == NULL || ifp == NULL ||
> @@ -265,27 +275,49 @@ axen_miibus_statchg(struct device *dev)
> return;
>
> val = 0;
> - if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0)
> + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0) {
> val |= AXEN_MEDIUM_FDX;
> + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_TXPAUSE) != 0)
> + val |= AXEN_MEDIUM_TXFLOW_CTRL_EN;
> + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_RXPAUSE) != 0)
> + val |= AXEN_MEDIUM_RXFLOW_CTRL_EN;
> + }
>
> - val |= (AXEN_MEDIUM_RECV_EN | AXEN_MEDIUM_ALWAYS_ONE);
> - val |= (AXEN_MEDIUM_RXFLOW_CTRL_EN | AXEN_MEDIUM_TXFLOW_CTRL_EN);
> + val |= AXEN_MEDIUM_RECV_EN;
>
> + /* bulkin queue setting */
> + axen_lock_mii(sc);
> + axen_cmd(sc, AXEN_CMD_MAC_READ, 1, AXEN_USB_UPLINK, );
> + axen_unlock_mii(sc);
> +
> switch (IFM_SUBTYPE(mii->mii_media_active)) {
> case IFM_1000_T:
> val |= AXEN_MEDIUM_GIGA | AXEN_MEDIUM_EN_125MHZ;
> + if (linkstat & AXEN_USB_SS)
> + qctrl = 0;
> + else if (linkstat & AXEN_USB_HS)
> + qctrl = 1;
> + else
> + qctrl = 3;
> break;
> case IFM_100_TX:
> val |= AXEN_MEDIUM_PS;
> + if (linkstat & (AXEN_USB_SS | AXEN_USB_HS))
> + qctrl = 2;
> + else
> + qctrl = 3;
> break;
> case IFM_10_T:
> - /* doesn't need to be handled */
> + default:
> + qctrl = 3;
> break;
> }
>
> DPRINTF(("axen_miibus_statchg: val=0x%x\n", val));
> USETW(wval, val);
> axen_lock_mii(sc);
> + axen_cmd(sc, AXEN_CMD_MAC_SET_RXSR, 5, AXEN_RX_BULKIN_QCTRL,
> + _bulk_size[qctrl]);
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
Hi, checksum err (pkt#1) appears in dmesg output only. Right now (after 43 hours of testing) there are 15 rows with checksum err (pkt#1) message. Previously, that network segment was connected by em(4), fxp(4), xl(4) drivers w/o any issues. So the error appears for axen(4) driver exclusively. It seems axen(4) related issue. Denis On 8/17/2018 6:26 PM, sc dying wrote: > Hi, > > On 2018/08/17 07:40, Denis wrote: >> Hi, >> >> 24 hour full load testing shows positive results. > > Good news. > >> >> After axen3.diff has been implemented there is no TX/RX error present at >> all. But 'checksum err (pkt#1)' appears repeatedly like this: >> >> ... >> checksum err (pkt#1) >> checksum err (pkt#1) >> checksum err (pkt#1) >> ... >> >> You're right DHCP client is working for axen0: >> >> # cat /etc/hostname.axen0 >> dhcp lladdr yy.yy.yy.yy.yy >> >> What can cause 'checksum err (pkt#1)' for axen? > > It might be another bug of axen(4), or someone on your ethernet segment > really sends bogus packets. > In latter case I don't think axen should report each error to the console. > >> >> Denis >> >> On 8/15/2018 2:29 AM, sc.dy...@gmail.com wrote: >>> Hi, >>> >>> On 2018/08/14 08:19, Denis wrote: I have 6.3 kernel compiled with option XHCI_debug and axen2.diff implemented. I'm using lladdr option for /etc/hostname.axen0 to have the same IP addr each session for different Ehternet adapters. Here is debug output when axen is connected: >>> >>> Thank you for sending report. >>> >>> It looks someone (maybe DHCP) makes the interface down and up repeatedly. >>> That causes TXERR (transaction error) on RX pipe. >>> I guess there is something inconsistent between the state of xhci and >>> the device. xhci spec 1.1 sec 4.3.5 requires the driver shall do >>> set_config and configure endpoint. >>> >>> I added set_config part to axen2.diff and attached as axen3.diff. >>> Can you try attached axen3.diff? >>> >>> Thanks. >>>
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
Hi, On 2018/08/17 07:40, Denis wrote: > Hi, > > 24 hour full load testing shows positive results. Good news. > > After axen3.diff has been implemented there is no TX/RX error present at > all. But 'checksum err (pkt#1)' appears repeatedly like this: > > ... > checksum err (pkt#1) > checksum err (pkt#1) > checksum err (pkt#1) > ... > > You're right DHCP client is working for axen0: > > # cat /etc/hostname.axen0 > dhcp lladdr yy.yy.yy.yy.yy > > What can cause 'checksum err (pkt#1)' for axen? It might be another bug of axen(4), or someone on your ethernet segment really sends bogus packets. In latter case I don't think axen should report each error to the console. > > Denis > > On 8/15/2018 2:29 AM, sc.dy...@gmail.com wrote: >> Hi, >> >> On 2018/08/14 08:19, Denis wrote: >>> I have 6.3 kernel compiled with option XHCI_debug and axen2.diff >>> implemented. >>> >>> I'm using lladdr option for /etc/hostname.axen0 to have the same IP addr >>> each session for different Ehternet adapters. >>> >>> Here is debug output when axen is connected: >> >> Thank you for sending report. >> >> It looks someone (maybe DHCP) makes the interface down and up repeatedly. >> That causes TXERR (transaction error) on RX pipe. >> I guess there is something inconsistent between the state of xhci and >> the device. xhci spec 1.1 sec 4.3.5 requires the driver shall do >> set_config and configure endpoint. >> >> I added set_config part to axen2.diff and attached as axen3.diff. >> Can you try attached axen3.diff? >> >> Thanks. >>
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
Hi, 24 hour full load testing shows positive results. After axen3.diff has been implemented there is no TX/RX error present at all. But 'checksum err (pkt#1)' appears repeatedly like this: ... checksum err (pkt#1) checksum err (pkt#1) checksum err (pkt#1) ... You're right DHCP client is working for axen0: # cat /etc/hostname.axen0 dhcp lladdr yy.yy.yy.yy.yy What can cause 'checksum err (pkt#1)' for axen? Denis On 8/15/2018 2:29 AM, sc.dy...@gmail.com wrote: > Hi, > > On 2018/08/14 08:19, Denis wrote: >> I have 6.3 kernel compiled with option XHCI_debug and axen2.diff >> implemented. >> >> I'm using lladdr option for /etc/hostname.axen0 to have the same IP addr >> each session for different Ehternet adapters. >> >> Here is debug output when axen is connected: > > Thank you for sending report. > > It looks someone (maybe DHCP) makes the interface down and up repeatedly. > That causes TXERR (transaction error) on RX pipe. > I guess there is something inconsistent between the state of xhci and > the device. xhci spec 1.1 sec 4.3.5 requires the driver shall do > set_config and configure endpoint. > > I added set_config part to axen2.diff and attached as axen3.diff. > Can you try attached axen3.diff? > > Thanks. > >> >> xhci0: port=2 change=0x04 >> xhci0: port=2 change=0x04 >> xhci0: xhci_cmd_slot_control >> xhci0: dev 1, input=0xff0001988000 slot=0xff0001988020 >> ep0=0xff0001988040 >> xhci0: dev 1, setting DCBAA to 0x01989000 >> xhci_pipe_init: pipe=0x80a8d000 addr=0 depth=1 port=2 speed=4 >> dev 1 dci 1 (epAddr=0x0) >> xhci0: xhci_cmd_set_address BSR=1 >> xhci0: xhci_cmd_set_address BSR=0 >> xhci0: dev 1 addr 1 >> axen0 at uhub0 port 2 configuration 1 interface 0 "ASIX Elec. Corp. >> AX88179" rev 3.00/1.00 addr 2 >> axen0: AX88179, address xx:xx:xx:xx:xx:xx >> ukphy0 at axen0 phy 3: Generic IEEE 802.3u media interface, rev. 5: OUI >> 0x000732, model 0x0011 >> xhci_pipe_init: pipe=0x80b38000 addr=2 depth=1 port=2 speed=4 >> dev 1 dci 5 (epAddr=0x82) >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci_pipe_init: pipe=0x80bfc000 addr=2 depth=1 port=2 speed=4 >> dev 1 dci 6 (epAddr=0x3) >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci_abort_xfer: xfer=0xff044e6aee10 status=IN_PROGRESS >> err=CANCELLED actlen=0 len=65536 idx=0 >> xhci0: xhci_cmd_stop_ep dev 1 dci 5 >> xhci_event_xfer: stopped xfer=0xff044e6aee10 >> xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 5 >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci_pipe_init: pipe=0x80b3a000 addr=2 depth=1 port=2 speed=4 >> dev 1 dci 5 (epAddr=0x82) >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci_pipe_init: pipe=0x80b3e000 addr=2 depth=1 port=2 speed=4 >> dev 1 dci 6 (epAddr=0x3) >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci_abort_xfer: xfer=0xff044e6aed20 status=IN_PROGRESS >> err=CANCELLED actlen=0 len=65536 idx=42 >> xhci0: xhci_cmd_stop_ep dev 1 dci 5 >> xhci_event_xfer: stopped xfer=0xff044e6aed20 >> xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 5 >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci_pipe_init: pipe=0x8079 addr=2 depth=1 port=2 speed=4 >> dev 1 dci 5 (epAddr=0x82) >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci_pipe_init: pipe=0x80791000 addr=2 depth=1 port=2 speed=4 >> dev 1 dci 6 (epAddr=0x3) >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci0: txerr? code 4 >> axen0: usb errors on rx: IOERROR >> xhci_abort_xfer: xfer=0xff044e6aee10 status=NOT_STARTED >> err=CANCELLED actlen=0 len=65536 idx=-1 >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci_pipe_init: pipe=0x807a9000 addr=2 depth=1 port=2 speed=4 >> dev 1 dci 5 (epAddr=0x82) >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci_pipe_init: pipe=0x807aa000 addr=2 depth=1 port=2 speed=4 >> dev 1 dci 6 (epAddr=0x3) >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci0: txerr? code 4 >> axen0: usb errors on rx: IOERROR >> xhci0: txerr? code 4 >> axen0: usb error on tx: IOERROR >> axen0: watchdog timeout >> axen0: usb error on tx: IOERROR >> xhci_abort_xfer: xfer=0xff044e6aed20 status=NOT_STARTED >> err=CANCELLED actlen=0 len=65536 idx=-1 >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci_pipe_init: pipe=0x80865000 addr=2 depth=1 port=2 speed=4 >> dev 1 dci 5 (epAddr=0x82) >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci_pipe_init: pipe=0x80866000 addr=2 depth=1 port=2 speed=4 >> dev 1 dci 6 (epAddr=0x3) >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci0: txerr? code 4 >> axen0: usb errors on rx: IOERROR >> xhci0: txerr? code 4 >> axen0: usb error on tx: IOERROR >> xhci_abort_xfer: xfer=0xff044e6aee10 status=NOT_STARTED >> err=CANCELLED actlen=0 len=65536 idx=-1 >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci0: xhci_cmd_configure_ep dev 1 >> xhci_pipe_init: pipe=0x8087e000 addr=2 depth=1 port=2 speed=4 >> dev 1 dci 5 (epAddr=0x82) >> xhci0:
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
Hi, On 2018/08/14 08:19, Denis wrote: > I have 6.3 kernel compiled with option XHCI_debug and axen2.diff > implemented. > > I'm using lladdr option for /etc/hostname.axen0 to have the same IP addr > each session for different Ehternet adapters. > > Here is debug output when axen is connected: Thank you for sending report. It looks someone (maybe DHCP) makes the interface down and up repeatedly. That causes TXERR (transaction error) on RX pipe. I guess there is something inconsistent between the state of xhci and the device. xhci spec 1.1 sec 4.3.5 requires the driver shall do set_config and configure endpoint. I added set_config part to axen2.diff and attached as axen3.diff. Can you try attached axen3.diff? Thanks. > > xhci0: port=2 change=0x04 > xhci0: port=2 change=0x04 > xhci0: xhci_cmd_slot_control > xhci0: dev 1, input=0xff0001988000 slot=0xff0001988020 > ep0=0xff0001988040 > xhci0: dev 1, setting DCBAA to 0x01989000 > xhci_pipe_init: pipe=0x80a8d000 addr=0 depth=1 port=2 speed=4 > dev 1 dci 1 (epAddr=0x0) > xhci0: xhci_cmd_set_address BSR=1 > xhci0: xhci_cmd_set_address BSR=0 > xhci0: dev 1 addr 1 > axen0 at uhub0 port 2 configuration 1 interface 0 "ASIX Elec. Corp. > AX88179" rev 3.00/1.00 addr 2 > axen0: AX88179, address xx:xx:xx:xx:xx:xx > ukphy0 at axen0 phy 3: Generic IEEE 802.3u media interface, rev. 5: OUI > 0x000732, model 0x0011 > xhci_pipe_init: pipe=0x80b38000 addr=2 depth=1 port=2 speed=4 > dev 1 dci 5 (epAddr=0x82) > xhci0: xhci_cmd_configure_ep dev 1 > xhci_pipe_init: pipe=0x80bfc000 addr=2 depth=1 port=2 speed=4 > dev 1 dci 6 (epAddr=0x3) > xhci0: xhci_cmd_configure_ep dev 1 > xhci_abort_xfer: xfer=0xff044e6aee10 status=IN_PROGRESS > err=CANCELLED actlen=0 len=65536 idx=0 > xhci0: xhci_cmd_stop_ep dev 1 dci 5 > xhci_event_xfer: stopped xfer=0xff044e6aee10 > xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 5 > xhci0: xhci_cmd_configure_ep dev 1 > xhci0: xhci_cmd_configure_ep dev 1 > xhci_pipe_init: pipe=0x80b3a000 addr=2 depth=1 port=2 speed=4 > dev 1 dci 5 (epAddr=0x82) > xhci0: xhci_cmd_configure_ep dev 1 > xhci_pipe_init: pipe=0x80b3e000 addr=2 depth=1 port=2 speed=4 > dev 1 dci 6 (epAddr=0x3) > xhci0: xhci_cmd_configure_ep dev 1 > xhci_abort_xfer: xfer=0xff044e6aed20 status=IN_PROGRESS > err=CANCELLED actlen=0 len=65536 idx=42 > xhci0: xhci_cmd_stop_ep dev 1 dci 5 > xhci_event_xfer: stopped xfer=0xff044e6aed20 > xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 5 > xhci0: xhci_cmd_configure_ep dev 1 > xhci0: xhci_cmd_configure_ep dev 1 > xhci_pipe_init: pipe=0x8079 addr=2 depth=1 port=2 speed=4 > dev 1 dci 5 (epAddr=0x82) > xhci0: xhci_cmd_configure_ep dev 1 > xhci_pipe_init: pipe=0x80791000 addr=2 depth=1 port=2 speed=4 > dev 1 dci 6 (epAddr=0x3) > xhci0: xhci_cmd_configure_ep dev 1 > xhci0: txerr? code 4 > axen0: usb errors on rx: IOERROR > xhci_abort_xfer: xfer=0xff044e6aee10 status=NOT_STARTED > err=CANCELLED actlen=0 len=65536 idx=-1 > xhci0: xhci_cmd_configure_ep dev 1 > xhci0: xhci_cmd_configure_ep dev 1 > xhci_pipe_init: pipe=0x807a9000 addr=2 depth=1 port=2 speed=4 > dev 1 dci 5 (epAddr=0x82) > xhci0: xhci_cmd_configure_ep dev 1 > xhci_pipe_init: pipe=0x807aa000 addr=2 depth=1 port=2 speed=4 > dev 1 dci 6 (epAddr=0x3) > xhci0: xhci_cmd_configure_ep dev 1 > xhci0: txerr? code 4 > axen0: usb errors on rx: IOERROR > xhci0: txerr? code 4 > axen0: usb error on tx: IOERROR > axen0: watchdog timeout > axen0: usb error on tx: IOERROR > xhci_abort_xfer: xfer=0xff044e6aed20 status=NOT_STARTED > err=CANCELLED actlen=0 len=65536 idx=-1 > xhci0: xhci_cmd_configure_ep dev 1 > xhci0: xhci_cmd_configure_ep dev 1 > xhci_pipe_init: pipe=0x80865000 addr=2 depth=1 port=2 speed=4 > dev 1 dci 5 (epAddr=0x82) > xhci0: xhci_cmd_configure_ep dev 1 > xhci_pipe_init: pipe=0x80866000 addr=2 depth=1 port=2 speed=4 > dev 1 dci 6 (epAddr=0x3) > xhci0: xhci_cmd_configure_ep dev 1 > xhci0: txerr? code 4 > axen0: usb errors on rx: IOERROR > xhci0: txerr? code 4 > axen0: usb error on tx: IOERROR > xhci_abort_xfer: xfer=0xff044e6aee10 status=NOT_STARTED > err=CANCELLED actlen=0 len=65536 idx=-1 > xhci0: xhci_cmd_configure_ep dev 1 > xhci0: xhci_cmd_configure_ep dev 1 > xhci_pipe_init: pipe=0x8087e000 addr=2 depth=1 port=2 speed=4 > dev 1 dci 5 (epAddr=0x82) > xhci0: xhci_cmd_configure_ep dev 1 > xhci_pipe_init: pipe=0x8087f000 addr=2 depth=1 port=2 speed=4 > dev 1 dci 6 (epAddr=0x3) > xhci0: xhci_cmd_configure_ep dev 1 > xhci0: txerr? code 4 > axen0: usb errors on rx: IOERROR > xhci0: txerr? code 4 > axen0: usb error on tx: IOERROR > axen0: watchdog timeout > > --- sys/dev/usb/if_axen.c.orig Sun Jan 22 10:17:39 2017 +++ sys/dev/usb/if_axen.c Tue Aug 14 22:11:18 2018 @@ -53,6 +53,7 @@ #include #include #include +#include #include @@ -121,6 +122,13 @@ void axen_unlock_mii(struct axen_softc *sc); void axen_ax88179_init(struct
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
I have 6.3 kernel compiled with option XHCI_debug and axen2.diff implemented. I'm using lladdr option for /etc/hostname.axen0 to have the same IP addr each session for different Ehternet adapters. Here is debug output when axen is connected: xhci0: port=2 change=0x04 xhci0: port=2 change=0x04 xhci0: xhci_cmd_slot_control xhci0: dev 1, input=0xff0001988000 slot=0xff0001988020 ep0=0xff0001988040 xhci0: dev 1, setting DCBAA to 0x01989000 xhci_pipe_init: pipe=0x80a8d000 addr=0 depth=1 port=2 speed=4 dev 1 dci 1 (epAddr=0x0) xhci0: xhci_cmd_set_address BSR=1 xhci0: xhci_cmd_set_address BSR=0 xhci0: dev 1 addr 1 axen0 at uhub0 port 2 configuration 1 interface 0 "ASIX Elec. Corp. AX88179" rev 3.00/1.00 addr 2 axen0: AX88179, address xx:xx:xx:xx:xx:xx ukphy0 at axen0 phy 3: Generic IEEE 802.3u media interface, rev. 5: OUI 0x000732, model 0x0011 xhci_pipe_init: pipe=0x80b38000 addr=2 depth=1 port=2 speed=4 dev 1 dci 5 (epAddr=0x82) xhci0: xhci_cmd_configure_ep dev 1 xhci_pipe_init: pipe=0x80bfc000 addr=2 depth=1 port=2 speed=4 dev 1 dci 6 (epAddr=0x3) xhci0: xhci_cmd_configure_ep dev 1 xhci_abort_xfer: xfer=0xff044e6aee10 status=IN_PROGRESS err=CANCELLED actlen=0 len=65536 idx=0 xhci0: xhci_cmd_stop_ep dev 1 dci 5 xhci_event_xfer: stopped xfer=0xff044e6aee10 xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 5 xhci0: xhci_cmd_configure_ep dev 1 xhci0: xhci_cmd_configure_ep dev 1 xhci_pipe_init: pipe=0x80b3a000 addr=2 depth=1 port=2 speed=4 dev 1 dci 5 (epAddr=0x82) xhci0: xhci_cmd_configure_ep dev 1 xhci_pipe_init: pipe=0x80b3e000 addr=2 depth=1 port=2 speed=4 dev 1 dci 6 (epAddr=0x3) xhci0: xhci_cmd_configure_ep dev 1 xhci_abort_xfer: xfer=0xff044e6aed20 status=IN_PROGRESS err=CANCELLED actlen=0 len=65536 idx=42 xhci0: xhci_cmd_stop_ep dev 1 dci 5 xhci_event_xfer: stopped xfer=0xff044e6aed20 xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 5 xhci0: xhci_cmd_configure_ep dev 1 xhci0: xhci_cmd_configure_ep dev 1 xhci_pipe_init: pipe=0x8079 addr=2 depth=1 port=2 speed=4 dev 1 dci 5 (epAddr=0x82) xhci0: xhci_cmd_configure_ep dev 1 xhci_pipe_init: pipe=0x80791000 addr=2 depth=1 port=2 speed=4 dev 1 dci 6 (epAddr=0x3) xhci0: xhci_cmd_configure_ep dev 1 xhci0: txerr? code 4 axen0: usb errors on rx: IOERROR xhci_abort_xfer: xfer=0xff044e6aee10 status=NOT_STARTED err=CANCELLED actlen=0 len=65536 idx=-1 xhci0: xhci_cmd_configure_ep dev 1 xhci0: xhci_cmd_configure_ep dev 1 xhci_pipe_init: pipe=0x807a9000 addr=2 depth=1 port=2 speed=4 dev 1 dci 5 (epAddr=0x82) xhci0: xhci_cmd_configure_ep dev 1 xhci_pipe_init: pipe=0x807aa000 addr=2 depth=1 port=2 speed=4 dev 1 dci 6 (epAddr=0x3) xhci0: xhci_cmd_configure_ep dev 1 xhci0: txerr? code 4 axen0: usb errors on rx: IOERROR xhci0: txerr? code 4 axen0: usb error on tx: IOERROR axen0: watchdog timeout axen0: usb error on tx: IOERROR xhci_abort_xfer: xfer=0xff044e6aed20 status=NOT_STARTED err=CANCELLED actlen=0 len=65536 idx=-1 xhci0: xhci_cmd_configure_ep dev 1 xhci0: xhci_cmd_configure_ep dev 1 xhci_pipe_init: pipe=0x80865000 addr=2 depth=1 port=2 speed=4 dev 1 dci 5 (epAddr=0x82) xhci0: xhci_cmd_configure_ep dev 1 xhci_pipe_init: pipe=0x80866000 addr=2 depth=1 port=2 speed=4 dev 1 dci 6 (epAddr=0x3) xhci0: xhci_cmd_configure_ep dev 1 xhci0: txerr? code 4 axen0: usb errors on rx: IOERROR xhci0: txerr? code 4 axen0: usb error on tx: IOERROR xhci_abort_xfer: xfer=0xff044e6aee10 status=NOT_STARTED err=CANCELLED actlen=0 len=65536 idx=-1 xhci0: xhci_cmd_configure_ep dev 1 xhci0: xhci_cmd_configure_ep dev 1 xhci_pipe_init: pipe=0x8087e000 addr=2 depth=1 port=2 speed=4 dev 1 dci 5 (epAddr=0x82) xhci0: xhci_cmd_configure_ep dev 1 xhci_pipe_init: pipe=0x8087f000 addr=2 depth=1 port=2 speed=4 dev 1 dci 6 (epAddr=0x3) xhci0: xhci_cmd_configure_ep dev 1 xhci0: txerr? code 4 axen0: usb errors on rx: IOERROR xhci0: txerr? code 4 axen0: usb error on tx: IOERROR axen0: watchdog timeout On 7/31/2018 11:08 AM, Denis wrote: > Hello, > > Thank you for patch. I can apply it a bit later in the trip currently. > > > > On 7/30/2018 3:11 AM, sc.dy...@gmail.com wrote: >> Hi, >> >> On 2018/07/27 09:14, Denis wrote: >>> Every time (after 2-3 minutes of work) ASIX Electronics USB-Ethernet >>> device reports: >>> >>> axen0: usb errors on rx: IOERROR >>> axen0: usb errors on rx: IOERROR >>> axen0: usb errors on tx: IOERROR >>> axen0: watchdog timeout >>> axen0: usb errors on tx: IOERROR >>> >>> The device hangs and must be reattached to have it working again for 2-3 >>> minutes. >> >> Do you want to try this patch? >> >> - >> - header: fix comments >> - header: fix unused L3 type mask definition >> - rxeof: Avoid allocating mbuf if checksum errors are detected. >> - rxeof: Avoid loop to extract packets if pkt_count is 0. >> - rxeof: Add more sanity checks. >> - rxeof: Increament if_ierror in some error paths. >> - qctrl: Apply queuing control parameters
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
On August 9, 2018 1:39 PM, sc dying wrote: > Hi, > > On Wed, Aug 8, 2018 at 9:24 AM, Denis den...@mindall.org wrote: > > > Hi, > > Using second diff applied to 6.3 sources and rebuilt kernel. > > The issue is persistent + new kernel error message: > > checksum err (pkt#1) > > axen0: usb errors on rs: IOERROR > > axen0: usb errors on rx: IOERROR > > axen0: usb error on tx: IOERROR > > axen0: watchdog timeout > > axen0: usb error on tx: IOERROR > > ... > > Right now axen is connected to USB3 if it will help. > > Hmm, no idea. > Does your dongle and PC work properly on other OSes? Compile kernel with XHCI_DEBUG to see if there's anything interesting there?
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
Hi, On Wed, Aug 8, 2018 at 9:24 AM, Denis wrote: > Hi, > > Using second diff applied to 6.3 sources and rebuilt kernel. > > The issue is persistent + new kernel error message: > > checksum err (pkt#1) > > axen0: usb errors on rs: IOERROR > axen0: usb errors on rx: IOERROR > axen0: usb error on tx: IOERROR > axen0: watchdog timeout > axen0: usb error on tx: IOERROR > ... > > Right now axen is connected to USB3 if it will help. Hmm, no idea. Does your dongle and PC work properly on other OSes?
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
Hi,
Using second diff applied to 6.3 sources and rebuilt kernel.
The issue is persistent + new kernel error message:
checksum err (pkt#1)
axen0: usb errors on rs: IOERROR
axen0: usb errors on rx: IOERROR
axen0: usb error on tx: IOERROR
axen0: watchdog timeout
axen0: usb error on tx: IOERROR
...
Right now axen is connected to USB3 if it will help.
On 7/30/2018 3:11 AM, sc.dy...@gmail.com wrote:
> Hi,
>
> On 2018/07/27 09:14, Denis wrote:
>> Every time (after 2-3 minutes of work) ASIX Electronics USB-Ethernet
>> device reports:
>>
>> axen0: usb errors on rx: IOERROR
>> axen0: usb errors on rx: IOERROR
>> axen0: usb errors on tx: IOERROR
>> axen0: watchdog timeout
>> axen0: usb errors on tx: IOERROR
>>
>> The device hangs and must be reattached to have it working again for 2-3
>> minutes.
>
> Do you want to try this patch?
>
> -
> - header: fix comments
> - header: fix unused L3 type mask definition
> - rxeof: Avoid allocating mbuf if checksum errors are detected.
> - rxeof: Avoid loop to extract packets if pkt_count is 0.
> - rxeof: Add more sanity checks.
> - rxeof: Increament if_ierror in some error paths.
> - qctrl: Apply queuing control parameters from FreeBSD axge(4).
> - qctrl: Set qctrl in miireg_statchg dynamically, not statically.
> - Use DMA buffer aligned at 64KB boundary to avoid xhci bug.
>
>
> --- sys/dev/usb/if_axenreg.h Fri Sep 16 22:17:07 2016
> +++ sys/dev/usb/if_axenreg.h Mon Jun 19 10:54:28 2017
> @@ -26,8 +26,8 @@
> * | | ++-L3_type (1:ipv4, 0/2:ipv6)
> * pkt_len(13) | | ||+ ++-L4_type(0: icmp, 1: UDP, 4: TCP)
> * |765|43210 76543210|7654 3210 7654 3210|
> - * ||+-crc_err |+-L4_err |+-L4_CSUM_ERR
> - * |+-mii_err +--L3_err +--L3_CSUM_ERR
> + * ||+-crc_err |+-L4_err |+-L4_CSUM_ERR
> + * |+-mii_err +--L3_err +--L3_CSUM_ERR
> * +-drop_err
> *
> * ex) pkt_hdr 0x00680820
> @@ -70,7 +70,7 @@
> #define AXEN_RXHDR_L4_TYPE_TCP 0x4
>
> /* L3 packet type (2bit) */
> -#define AXEN_RXHDR_L3_TYPE_MASK 0x0600
> +#define AXEN_RXHDR_L3_TYPE_MASK 0x0060
> #define AXEN_RXHDR_L3_TYPE_OFFSET 5
> #define AXEN_RXHDR_L3_TYPE_UNDEF 0x0
> #define AXEN_RXHDR_L3_TYPE_IPV4 0x1
> --- sys/dev/usb/if_axen.c.orig Tue Jun 12 15:36:59 2018
> +++ sys/dev/usb/if_axen.c Sun Jul 29 01:53:43 2018
> @@ -53,6 +53,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -121,6 +122,13 @@ void axen_unlock_mii(struct axen_softc *sc);
>
> void axen_ax88179_init(struct axen_softc *);
>
> +struct axen_qctrl axen_bulk_size[] = {
> + { 7, 0x4f, 0x00, 0x12, 0xff },
> + { 7, 0x20, 0x03, 0x16, 0xff },
> + { 7, 0xae, 0x07, 0x18, 0xff },
> + { 7, 0xcc, 0x4c, 0x18, 0x08 }
> +};
> +
> /* Get exclusive access to the MII registers */
> void
> axen_lock_mii(struct axen_softc *sc)
> @@ -238,6 +246,8 @@ axen_miibus_statchg(struct device *dev)
> int err;
> uint16_t val;
> uWord wval;
> + uint8_t linkstat = 0;
> + int qctrl;
>
> ifp = GET_IFP(sc);
> if (mii == NULL || ifp == NULL ||
> @@ -265,27 +275,49 @@ axen_miibus_statchg(struct device *dev)
> return;
>
> val = 0;
> - if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0)
> + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0) {
> val |= AXEN_MEDIUM_FDX;
> + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_TXPAUSE) != 0)
> + val |= AXEN_MEDIUM_TXFLOW_CTRL_EN;
> + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_RXPAUSE) != 0)
> + val |= AXEN_MEDIUM_RXFLOW_CTRL_EN;
> + }
>
> - val |= (AXEN_MEDIUM_RECV_EN | AXEN_MEDIUM_ALWAYS_ONE);
> - val |= (AXEN_MEDIUM_RXFLOW_CTRL_EN | AXEN_MEDIUM_TXFLOW_CTRL_EN);
> + val |= AXEN_MEDIUM_RECV_EN;
>
> + /* bulkin queue setting */
> + axen_lock_mii(sc);
> + axen_cmd(sc, AXEN_CMD_MAC_READ, 1, AXEN_USB_UPLINK, );
> + axen_unlock_mii(sc);
> +
> switch (IFM_SUBTYPE(mii->mii_media_active)) {
> case IFM_1000_T:
> val |= AXEN_MEDIUM_GIGA | AXEN_MEDIUM_EN_125MHZ;
> + if (linkstat & AXEN_USB_SS)
> + qctrl = 0;
> + else if (linkstat & AXEN_USB_HS)
> + qctrl = 1;
> + else
> + qctrl = 3;
> break;
> case IFM_100_TX:
> val |= AXEN_MEDIUM_PS;
> + if (linkstat & (AXEN_USB_SS | AXEN_USB_HS))
> + qctrl = 2;
> + else
> + qctrl = 3;
> break;
> case IFM_10_T:
> - /* doesn't need to be handled */
> + default:
> + qctrl = 3;
> break;
> }
>
> DPRINTF(("axen_miibus_statchg: val=0x%x\n", val));
> USETW(wval, val);
> axen_lock_mii(sc);
> + axen_cmd(sc, AXEN_CMD_MAC_SET_RXSR, 5, AXEN_RX_BULKIN_QCTRL,
> + _bulk_size[qctrl]);
> err = axen_cmd(sc,
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
Hi,
On 2018/08/07 09:23, Denis wrote:
Hi,
axen.patch.1st has been applied to CURRENT src tree fetched from
official CVS with errors listed before.
Second patch has been applied to sources from official CVS -rOPENBSD_6_3
src. To test it one more time I've unpacked src.tar.gz and sys.tar.gz
from 6.3amd64 distribution CD and try axen.patch.2nd one more time...
the same errors like from official CVS.
What can be wrong?
It is a whitespace problem caused by my mailer.
I attached both patches. I hope they help you.
- header: fix comments
- header: fix unused L3 type mask definition
- rxeof: Avoid allocating mbuf if checksum errors are detected.
- rxeof: Avoid loop to extract packets if pkt_count is 0.
- rxeof: Add more sanity checks.
- rxeof: Increament if_ierror in some error paths.
- qctrl: Apply queuing control parameters from FreeBSD axge(4).
- qctrl: Set qctrl in miireg_statchg dynamically, not statically.
- Use DMA buffer aligned at 64KB boundary to avoid xhci bug.
--- sys/dev/usb/if_axenreg.hFri Sep 16 22:17:07 2016
+++ sys/dev/usb/if_axenreg.hMon Jun 19 10:54:28 2017
@@ -26,8 +26,8 @@
* || ++-L3_type (1:ipv4, 0/2:ipv6)
*pkt_len(13) || ||+ ++-L4_type(0: icmp, 1: UDP, 4: TCP)
* |765|43210 76543210|7654 3210 7654 3210|
- * ||+-crc_err |+-L4_err |+-L4_CSUM_ERR
- * |+-mii_err +--L3_err +--L3_CSUM_ERR
+ * ||+-crc_err |+-L4_err |+-L4_CSUM_ERR
+ * |+-mii_err+--L3_err +--L3_CSUM_ERR
* +-drop_err
*
* ex) pkt_hdr 0x00680820
@@ -70,7 +70,7 @@
#define AXEN_RXHDR_L4_TYPE_TCP 0x4
/* L3 packet type (2bit) */
-#define AXEN_RXHDR_L3_TYPE_MASK0x0600
+#define AXEN_RXHDR_L3_TYPE_MASK0x0060
#define AXEN_RXHDR_L3_TYPE_OFFSET 5
#define AXEN_RXHDR_L3_TYPE_UNDEF 0x0
#define AXEN_RXHDR_L3_TYPE_IPV4 0x1
--- sys/dev/usb/if_axen.c.orig Tue Jun 12 15:36:59 2018
+++ sys/dev/usb/if_axen.c Sun Jul 29 01:53:43 2018
@@ -53,6 +53,7 @@
#include
#include
#include
+#include
#include
@@ -121,6 +122,13 @@ void axen_unlock_mii(struct axen_softc *sc);
void axen_ax88179_init(struct axen_softc *);
+struct axen_qctrl axen_bulk_size[] = {
+ { 7, 0x4f, 0x00, 0x12, 0xff },
+ { 7, 0x20, 0x03, 0x16, 0xff },
+ { 7, 0xae, 0x07, 0x18, 0xff },
+ { 7, 0xcc, 0x4c, 0x18, 0x08 }
+};
+
/* Get exclusive access to the MII registers */
void
axen_lock_mii(struct axen_softc *sc)
@@ -238,6 +246,8 @@ axen_miibus_statchg(struct device *dev)
int err;
uint16_tval;
uWord wval;
+ uint8_t linkstat = 0;
+ int qctrl;
ifp = GET_IFP(sc);
if (mii == NULL || ifp == NULL ||
@@ -265,27 +275,49 @@ axen_miibus_statchg(struct device *dev)
return;
val = 0;
- if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0)
+ if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0) {
val |= AXEN_MEDIUM_FDX;
+ if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_TXPAUSE) != 0)
+ val |= AXEN_MEDIUM_TXFLOW_CTRL_EN;
+ if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_RXPAUSE) != 0)
+ val |= AXEN_MEDIUM_RXFLOW_CTRL_EN;
+ }
- val |= (AXEN_MEDIUM_RECV_EN | AXEN_MEDIUM_ALWAYS_ONE);
- val |= (AXEN_MEDIUM_RXFLOW_CTRL_EN | AXEN_MEDIUM_TXFLOW_CTRL_EN);
+ val |= AXEN_MEDIUM_RECV_EN;
+ /* bulkin queue setting */
+ axen_lock_mii(sc);
+ axen_cmd(sc, AXEN_CMD_MAC_READ, 1, AXEN_USB_UPLINK, );
+ axen_unlock_mii(sc);
+
switch (IFM_SUBTYPE(mii->mii_media_active)) {
case IFM_1000_T:
val |= AXEN_MEDIUM_GIGA | AXEN_MEDIUM_EN_125MHZ;
+ if (linkstat & AXEN_USB_SS)
+ qctrl = 0;
+ else if (linkstat & AXEN_USB_HS)
+ qctrl = 1;
+ else
+ qctrl = 3;
break;
case IFM_100_TX:
val |= AXEN_MEDIUM_PS;
+ if (linkstat & (AXEN_USB_SS | AXEN_USB_HS))
+ qctrl = 2;
+ else
+ qctrl = 3;
break;
case IFM_10_T:
- /* doesn't need to be handled */
+ default:
+ qctrl = 3;
break;
}
DPRINTF(("axen_miibus_statchg: val=0x%x\n", val));
USETW(wval, val);
axen_lock_mii(sc);
+ axen_cmd(sc, AXEN_CMD_MAC_SET_RXSR, 5, AXEN_RX_BULKIN_QCTRL,
+ _bulk_size[qctrl]);
err = axen_cmd(sc, AXEN_CMD_MAC_WRITE2, 2, AXEN_MEDIUM_STATUS, );
axen_unlock_mii(sc);
if (err) {
@@ -408,7 +440,6 @@ axen_ax88179_init(struct axen_softc *sc)
uWord wval;
uByte val;
u_int16_t
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
Hi,
axen.patch.1st has been applied to CURRENT src tree fetched from
official CVS with errors listed before.
Second patch has been applied to sources from official CVS -rOPENBSD_6_3
src. To test it one more time I've unpacked src.tar.gz and sys.tar.gz
from 6.3amd64 distribution CD and try axen.patch.2nd one more time...
the same errors like from official CVS.
What can be wrong?
# patch -p0 < axen.patch.2nd
Hmm.. Lookd like a unified diff to me...
The text leading up to this was:
-
|--- sys/dev/usb/if_axen.c.orig Sun Jan 22 10:17:39 2017
|+++ sys/dev/usb/if_axen.c Mon Aug 6 23:20:25 2018
-
Patching file sys/dev/usb/if_axen.c using Plan A...
Hunk #1 succeeded at 53.
Hunk #2 succeeded at 122 with fuzz 2.
Hunk #3 failed at 246.
Hunk #4 failed at 275.
Hunk #5 failed at 440.
Hunk #6 failed at 501.
Hunk #7 failed at 635.
Hunk #8 failed at 709.
Hunk #9 succeeded at 808 with fuzz 1.
Hunk #10 failed at 844.
Hunk #11 failed at 875.
8 out of 11 hunks failed--saving rejects to sys/dev/usb/if_axen.c.rej
done
On 8/7/2018 3:40 AM, sc.dy...@gmail.com wrote:
> Hi,
>
> On 2018/08/05 15:31, Denis wrote:
>> Can not patch original files in /usr/src/sys/dev/usb/ despite that
>> if_axenreg.h and if_axen.c files fetched directly from current CVS repo.
>
> Previous patch is for -current, but perhaps your source version is 6.3.
> Please try the new patch below for 6.3.
>
> The dmesg in the report says "OpenBSD 6.3", I missed it.
> Sorry about that.
>
>>
>> # patch -p0 < axen.patch
>> Hmm.. Lookd like a unified diff to me...
>> The text leading up to this was:
>> -
>> |--- sys/dev/usb/if_axenreg.h Fri Sep 16 22:17:07 2016
>> |+++ sys/dev/usb/if_axenreg.h Mon Jun 19 10:54:28 2017
>> -
>> Patching file sys/dev/usb/if_axenreg.h using Plan A...
>> Hunk #1 succeeded at 26.
>> Hunk #2 failed at 70.
>> 1 out of 2 hunks failed--saving rejects to sys/dev/usb/if_axenreg.h.rej
>> Hmm... The next patch look like a unified diff to me...
>> The text leading up to this was:
>> -
>> |--- sys/dev/usb/if_axen.c.orig Tue Jun 12 15:36:59 2018
>> |+++ sys/dev/usb/if_axen.c Sun Jul 29 01:53:43 2018
>> -
>> Patching file sys/dev/usb/if_axen.c using Plan A...
>> Hunk #1 succeeded at 53.
>> Hunk #2 succeeded at 122 with fuzz 2.
>> Hunk #3 failed at 246.
>> Hunk #4 failed at 275.
>> Hunk #5 failed at 440.
>> Hunk #6 failed at 502.
>> Hunk #7 failed at 515.
>> Hunk #8 failed at 637.
>> Hunk #9 failed at 711.
>> Hunk #10 succeeded at 810 with fuzz 1.
>> Hunk #11 failed at 846.
>> Hunk #12 failed at 877.
>> Hunk #13 failed at 907.
>> Hunk #14 failed at 932.
>> Hunk #15 failed at 955.
>> Hunk #16 failed at 975.
>> Hunk #17 failed at 996.
>> Hunk #18 failed at 1029.
>> Hunk #19 failed at 1054.
>> 16 out of 19 hunks failed--saving rejects to sys/dev/usb/if_axen.c.rej
>> done
>
> - Only qctrl and buffer allocation are changed.
> (Omit some non-essential parts. It should work.)
>
>
> --- sys/dev/usb/if_axen.c.orig Sun Jan 22 10:17:39 2017
> +++ sys/dev/usb/if_axen.c Mon Aug 6 23:20:25 2018
> @@ -53,6 +53,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -121,6 +122,13 @@ void axen_unlock_mii(struct axen_softc *sc);
>
> void axen_ax88179_init(struct axen_softc *);
>
> +struct axen_qctrl axen_bulk_size[] = {
> + { 7, 0x4f, 0x00, 0x12, 0xff },
> + { 7, 0x20, 0x03, 0x16, 0xff },
> + { 7, 0xae, 0x07, 0x18, 0xff },
> + { 7, 0xcc, 0x4c, 0x18, 0x08 }
> +};
> +
> /* Get exclusive access to the MII registers */
> void
> axen_lock_mii(struct axen_softc *sc)
> @@ -238,6 +246,8 @@ axen_miibus_statchg(struct device *dev)
> int err;
> uint16_t val;
> uWord wval;
> + uint8_t linkstat = 0;
> + int qctrl;
>
> ifp = GET_IFP(sc);
> if (mii == NULL || ifp == NULL ||
> @@ -265,27 +275,49 @@ axen_miibus_statchg(struct device *dev)
> return;
>
> val = 0;
> - if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0)
> + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0) {
> val |= AXEN_MEDIUM_FDX;
> + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_TXPAUSE) != 0)
> + val |= AXEN_MEDIUM_TXFLOW_CTRL_EN;
> + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_RXPAUSE) != 0)
> + val |= AXEN_MEDIUM_RXFLOW_CTRL_EN;
> + }
>
> - val |= (AXEN_MEDIUM_RECV_EN | AXEN_MEDIUM_ALWAYS_ONE);
> - val |= (AXEN_MEDIUM_RXFLOW_CTRL_EN | AXEN_MEDIUM_TXFLOW_CTRL_EN);
> + val |= AXEN_MEDIUM_RECV_EN;
>
> + /* bulkin queue setting */
> + axen_lock_mii(sc);
> + axen_cmd(sc, AXEN_CMD_MAC_READ, 1, AXEN_USB_UPLINK, );
> + axen_unlock_mii(sc);
> +
> switch (IFM_SUBTYPE(mii->mii_media_active)) {
> case IFM_1000_T:
> val |= AXEN_MEDIUM_GIGA | AXEN_MEDIUM_EN_125MHZ;
> + if (linkstat
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
Hi,
On 2018/08/05 15:31, Denis wrote:
Can not patch original files in /usr/src/sys/dev/usb/ despite that
if_axenreg.h and if_axen.c files fetched directly from current CVS repo.
Previous patch is for -current, but perhaps your source version is 6.3.
Please try the new patch below for 6.3.
The dmesg in the report says "OpenBSD 6.3", I missed it.
Sorry about that.
# patch -p0 < axen.patch
Hmm.. Lookd like a unified diff to me...
The text leading up to this was:
-
|--- sys/dev/usb/if_axenreg.h Fri Sep 16 22:17:07 2016
|+++ sys/dev/usb/if_axenreg.h Mon Jun 19 10:54:28 2017
-
Patching file sys/dev/usb/if_axenreg.h using Plan A...
Hunk #1 succeeded at 26.
Hunk #2 failed at 70.
1 out of 2 hunks failed--saving rejects to sys/dev/usb/if_axenreg.h.rej
Hmm... The next patch look like a unified diff to me...
The text leading up to this was:
-
|--- sys/dev/usb/if_axen.c.orig Tue Jun 12 15:36:59 2018
|+++ sys/dev/usb/if_axen.c Sun Jul 29 01:53:43 2018
-
Patching file sys/dev/usb/if_axen.c using Plan A...
Hunk #1 succeeded at 53.
Hunk #2 succeeded at 122 with fuzz 2.
Hunk #3 failed at 246.
Hunk #4 failed at 275.
Hunk #5 failed at 440.
Hunk #6 failed at 502.
Hunk #7 failed at 515.
Hunk #8 failed at 637.
Hunk #9 failed at 711.
Hunk #10 succeeded at 810 with fuzz 1.
Hunk #11 failed at 846.
Hunk #12 failed at 877.
Hunk #13 failed at 907.
Hunk #14 failed at 932.
Hunk #15 failed at 955.
Hunk #16 failed at 975.
Hunk #17 failed at 996.
Hunk #18 failed at 1029.
Hunk #19 failed at 1054.
16 out of 19 hunks failed--saving rejects to sys/dev/usb/if_axen.c.rej
done
- Only qctrl and buffer allocation are changed.
(Omit some non-essential parts. It should work.)
--- sys/dev/usb/if_axen.c.orig Sun Jan 22 10:17:39 2017
+++ sys/dev/usb/if_axen.c Mon Aug 6 23:20:25 2018
@@ -53,6 +53,7 @@
#include
#include
#include
+#include
#include
@@ -121,6 +122,13 @@ void axen_unlock_mii(struct axen_softc *sc);
void axen_ax88179_init(struct axen_softc *);
+struct axen_qctrl axen_bulk_size[] = {
+ { 7, 0x4f, 0x00, 0x12, 0xff },
+ { 7, 0x20, 0x03, 0x16, 0xff },
+ { 7, 0xae, 0x07, 0x18, 0xff },
+ { 7, 0xcc, 0x4c, 0x18, 0x08 }
+};
+
/* Get exclusive access to the MII registers */
void
axen_lock_mii(struct axen_softc *sc)
@@ -238,6 +246,8 @@ axen_miibus_statchg(struct device *dev)
int err;
uint16_tval;
uWord wval;
+ uint8_t linkstat = 0;
+ int qctrl;
ifp = GET_IFP(sc);
if (mii == NULL || ifp == NULL ||
@@ -265,27 +275,49 @@ axen_miibus_statchg(struct device *dev)
return;
val = 0;
- if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0)
+ if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0) {
val |= AXEN_MEDIUM_FDX;
+ if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_TXPAUSE) != 0)
+ val |= AXEN_MEDIUM_TXFLOW_CTRL_EN;
+ if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_RXPAUSE) != 0)
+ val |= AXEN_MEDIUM_RXFLOW_CTRL_EN;
+ }
- val |= (AXEN_MEDIUM_RECV_EN | AXEN_MEDIUM_ALWAYS_ONE);
- val |= (AXEN_MEDIUM_RXFLOW_CTRL_EN | AXEN_MEDIUM_TXFLOW_CTRL_EN);
+ val |= AXEN_MEDIUM_RECV_EN;
+ /* bulkin queue setting */
+ axen_lock_mii(sc);
+ axen_cmd(sc, AXEN_CMD_MAC_READ, 1, AXEN_USB_UPLINK, );
+ axen_unlock_mii(sc);
+
switch (IFM_SUBTYPE(mii->mii_media_active)) {
case IFM_1000_T:
val |= AXEN_MEDIUM_GIGA | AXEN_MEDIUM_EN_125MHZ;
+ if (linkstat & AXEN_USB_SS)
+ qctrl = 0;
+ else if (linkstat & AXEN_USB_HS)
+ qctrl = 1;
+ else
+ qctrl = 3;
break;
case IFM_100_TX:
val |= AXEN_MEDIUM_PS;
+ if (linkstat & (AXEN_USB_SS | AXEN_USB_HS))
+ qctrl = 2;
+ else
+ qctrl = 3;
break;
case IFM_10_T:
- /* doesn't need to be handled */
+ default:
+ qctrl = 3;
break;
}
DPRINTF(("axen_miibus_statchg: val=0x%x\n", val));
USETW(wval, val);
axen_lock_mii(sc);
+ axen_cmd(sc, AXEN_CMD_MAC_SET_RXSR, 5, AXEN_RX_BULKIN_QCTRL,
+ _bulk_size[qctrl]);
err = axen_cmd(sc, AXEN_CMD_MAC_WRITE2, 2, AXEN_MEDIUM_STATUS, );
axen_unlock_mii(sc);
if (err) {
@@ -408,7 +440,6 @@ axen_ax88179_init(struct axen_softc *sc)
uWord wval;
uByte val;
u_int16_t ctl, temp;
- struct axen_qctrl qctrl;
axen_lock_mii(sc);
@@ -470,34 +501,18 @@ axen_ax88179_init(struct axen_softc *sc)
switch (val) {
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
Can not patch original files in /usr/src/sys/dev/usb/ despite that
if_axenreg.h and if_axen.c files fetched directly from current CVS repo.
# patch -p0 < axen.patch
Hmm.. Lookd like a unified diff to me...
The text leading up to this was:
-
|--- sys/dev/usb/if_axenreg.h Fri Sep 16 22:17:07 2016
|+++ sys/dev/usb/if_axenreg.h Mon Jun 19 10:54:28 2017
-
Patching file sys/dev/usb/if_axenreg.h using Plan A...
Hunk #1 succeeded at 26.
Hunk #2 failed at 70.
1 out of 2 hunks failed--saving rejects to sys/dev/usb/if_axenreg.h.rej
Hmm... The next patch look like a unified diff to me...
The text leading up to this was:
-
|--- sys/dev/usb/if_axen.c.orig Tue Jun 12 15:36:59 2018
|+++ sys/dev/usb/if_axen.c Sun Jul 29 01:53:43 2018
-
Patching file sys/dev/usb/if_axen.c using Plan A...
Hunk #1 succeeded at 53.
Hunk #2 succeeded at 122 with fuzz 2.
Hunk #3 failed at 246.
Hunk #4 failed at 275.
Hunk #5 failed at 440.
Hunk #6 failed at 502.
Hunk #7 failed at 515.
Hunk #8 failed at 637.
Hunk #9 failed at 711.
Hunk #10 succeeded at 810 with fuzz 1.
Hunk #11 failed at 846.
Hunk #12 failed at 877.
Hunk #13 failed at 907.
Hunk #14 failed at 932.
Hunk #15 failed at 955.
Hunk #16 failed at 975.
Hunk #17 failed at 996.
Hunk #18 failed at 1029.
Hunk #19 failed at 1054.
16 out of 19 hunks failed--saving rejects to sys/dev/usb/if_axen.c.rej
done
On 7/30/2018 3:11 AM, sc.dy...@gmail.com wrote:
> Hi,
>
> On 2018/07/27 09:14, Denis wrote:
>> Every time (after 2-3 minutes of work) ASIX Electronics USB-Ethernet
>> device reports:
>>
>> axen0: usb errors on rx: IOERROR
>> axen0: usb errors on rx: IOERROR
>> axen0: usb errors on tx: IOERROR
>> axen0: watchdog timeout
>> axen0: usb errors on tx: IOERROR
>>
>> The device hangs and must be reattached to have it working again for 2-3
>> minutes.
>
> Do you want to try this patch?
>
> -
> - header: fix comments
> - header: fix unused L3 type mask definition
> - rxeof: Avoid allocating mbuf if checksum errors are detected.
> - rxeof: Avoid loop to extract packets if pkt_count is 0.
> - rxeof: Add more sanity checks.
> - rxeof: Increament if_ierror in some error paths.
> - qctrl: Apply queuing control parameters from FreeBSD axge(4).
> - qctrl: Set qctrl in miireg_statchg dynamically, not statically.
> - Use DMA buffer aligned at 64KB boundary to avoid xhci bug.
>
>
> --- sys/dev/usb/if_axenreg.h Fri Sep 16 22:17:07 2016
> +++ sys/dev/usb/if_axenreg.h Mon Jun 19 10:54:28 2017
> @@ -26,8 +26,8 @@
> * | | ++-L3_type (1:ipv4, 0/2:ipv6)
> * pkt_len(13) | | ||+ ++-L4_type(0: icmp, 1: UDP, 4: TCP)
> * |765|43210 76543210|7654 3210 7654 3210|
> - * ||+-crc_err |+-L4_err |+-L4_CSUM_ERR
> - * |+-mii_err +--L3_err +--L3_CSUM_ERR
> + * ||+-crc_err |+-L4_err |+-L4_CSUM_ERR
> + * |+-mii_err +--L3_err +--L3_CSUM_ERR
> * +-drop_err
> *
> * ex) pkt_hdr 0x00680820
> @@ -70,7 +70,7 @@
> #define AXEN_RXHDR_L4_TYPE_TCP 0x4
>
> /* L3 packet type (2bit) */
> -#define AXEN_RXHDR_L3_TYPE_MASK 0x0600
> +#define AXEN_RXHDR_L3_TYPE_MASK 0x0060
> #define AXEN_RXHDR_L3_TYPE_OFFSET 5
> #define AXEN_RXHDR_L3_TYPE_UNDEF 0x0
> #define AXEN_RXHDR_L3_TYPE_IPV4 0x1
> --- sys/dev/usb/if_axen.c.orig Tue Jun 12 15:36:59 2018
> +++ sys/dev/usb/if_axen.c Sun Jul 29 01:53:43 2018
> @@ -53,6 +53,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -121,6 +122,13 @@ void axen_unlock_mii(struct axen_softc *sc);
>
> void axen_ax88179_init(struct axen_softc *);
>
> +struct axen_qctrl axen_bulk_size[] = {
> + { 7, 0x4f, 0x00, 0x12, 0xff },
> + { 7, 0x20, 0x03, 0x16, 0xff },
> + { 7, 0xae, 0x07, 0x18, 0xff },
> + { 7, 0xcc, 0x4c, 0x18, 0x08 }
> +};
> +
> /* Get exclusive access to the MII registers */
> void
> axen_lock_mii(struct axen_softc *sc)
> @@ -238,6 +246,8 @@ axen_miibus_statchg(struct device *dev)
> int err;
> uint16_t val;
> uWord wval;
> + uint8_t linkstat = 0;
> + int qctrl;
>
> ifp = GET_IFP(sc);
> if (mii == NULL || ifp == NULL ||
> @@ -265,27 +275,49 @@ axen_miibus_statchg(struct device *dev)
> return;
>
> val = 0;
> - if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0)
> + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0) {
> val |= AXEN_MEDIUM_FDX;
> + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_TXPAUSE) != 0)
> + val |= AXEN_MEDIUM_TXFLOW_CTRL_EN;
> + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_RXPAUSE) != 0)
> + val |= AXEN_MEDIUM_RXFLOW_CTRL_EN;
> + }
>
> - val |= (AXEN_MEDIUM_RECV_EN | AXEN_MEDIUM_ALWAYS_ONE);
> - val |= (AXEN_MEDIUM_RXFLOW_CTRL_EN | AXEN_MEDIUM_TXFLOW_CTRL_EN);
> + val |=
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
On Mon, Jul 30, 2018 at 12:11 AM, wrote: > - Use DMA buffer aligned at 64KB boundary to avoid xhci bug. In function xhci_event_xfer() xfer->actlen should be calculated from sum of transferred TRB length, not xfer->length - remain, when the transfer is splitted to multiple TRBs. The xhci driver may split a transfer into multiple TRBs if the DMA buffer is larger than 64kB or crosses 64kB boundary. For the example of unpatched axen, 24kB buffer of SS Bulk-In transfer might be spliited like following. TRB #0 bulk-in len 0x1000 paddr 0xda3ff000 (CHAIN) TRB #1 bulk-in len 0x5000 paddr 0xda40 (IOC) On the completion of each TRB xhci_event_xfer() calculates actlen. The size of inbound packet is usually less than given buffer size, TRB #0 ends up with SHORT_XFER and TRB #1 ends up with SUCCESS. bulk-in idx 2 last 3 len 0x6000 remain 0xf98 (for TRB #0) bulk-in idx 3 last 3 len 0x6000 remain 0x5000 (for TRB #1) For TRB #0, the actlen is xfer->length - remain = 0x6000 - 0xf98 = 0x5068. This value is stored in xfer->actlen. The actlen of #1 is 0x6000 - 0x5000 = 0x1000, but xfer->actlen is not zero so the actlen of #1 is ignored. Thus the actlen of this transfer is determined to be 0x5068, however, it is actually 0x68. When axen works on USB2 the unpatched axen uses 16kB buffer. It's smaller than 24kB of SS, less possible the buffer crosses 64kB boundary, you might not meet the problem.
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
Hello,
Thank you for patch. I can apply it a bit later in the trip currently.
On 7/30/2018 3:11 AM, sc.dy...@gmail.com wrote:
> Hi,
>
> On 2018/07/27 09:14, Denis wrote:
>> Every time (after 2-3 minutes of work) ASIX Electronics USB-Ethernet
>> device reports:
>>
>> axen0: usb errors on rx: IOERROR
>> axen0: usb errors on rx: IOERROR
>> axen0: usb errors on tx: IOERROR
>> axen0: watchdog timeout
>> axen0: usb errors on tx: IOERROR
>>
>> The device hangs and must be reattached to have it working again for 2-3
>> minutes.
>
> Do you want to try this patch?
>
> -
> - header: fix comments
> - header: fix unused L3 type mask definition
> - rxeof: Avoid allocating mbuf if checksum errors are detected.
> - rxeof: Avoid loop to extract packets if pkt_count is 0.
> - rxeof: Add more sanity checks.
> - rxeof: Increament if_ierror in some error paths.
> - qctrl: Apply queuing control parameters from FreeBSD axge(4).
> - qctrl: Set qctrl in miireg_statchg dynamically, not statically.
> - Use DMA buffer aligned at 64KB boundary to avoid xhci bug.
>
>
> --- sys/dev/usb/if_axenreg.h Fri Sep 16 22:17:07 2016
> +++ sys/dev/usb/if_axenreg.h Mon Jun 19 10:54:28 2017
> @@ -26,8 +26,8 @@
> * | | ++-L3_type (1:ipv4, 0/2:ipv6)
> * pkt_len(13) | | ||+ ++-L4_type(0: icmp, 1: UDP, 4: TCP)
> * |765|43210 76543210|7654 3210 7654 3210|
> - * ||+-crc_err |+-L4_err |+-L4_CSUM_ERR
> - * |+-mii_err +--L3_err +--L3_CSUM_ERR
> + * ||+-crc_err |+-L4_err |+-L4_CSUM_ERR
> + * |+-mii_err +--L3_err +--L3_CSUM_ERR
> * +-drop_err
> *
> * ex) pkt_hdr 0x00680820
> @@ -70,7 +70,7 @@
> #define AXEN_RXHDR_L4_TYPE_TCP 0x4
>
> /* L3 packet type (2bit) */
> -#define AXEN_RXHDR_L3_TYPE_MASK 0x0600
> +#define AXEN_RXHDR_L3_TYPE_MASK 0x0060
> #define AXEN_RXHDR_L3_TYPE_OFFSET 5
> #define AXEN_RXHDR_L3_TYPE_UNDEF 0x0
> #define AXEN_RXHDR_L3_TYPE_IPV4 0x1
> --- sys/dev/usb/if_axen.c.orig Tue Jun 12 15:36:59 2018
> +++ sys/dev/usb/if_axen.c Sun Jul 29 01:53:43 2018
> @@ -53,6 +53,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -121,6 +122,13 @@ void axen_unlock_mii(struct axen_softc *sc);
>
> void axen_ax88179_init(struct axen_softc *);
>
> +struct axen_qctrl axen_bulk_size[] = {
> + { 7, 0x4f, 0x00, 0x12, 0xff },
> + { 7, 0x20, 0x03, 0x16, 0xff },
> + { 7, 0xae, 0x07, 0x18, 0xff },
> + { 7, 0xcc, 0x4c, 0x18, 0x08 }
> +};
> +
> /* Get exclusive access to the MII registers */
> void
> axen_lock_mii(struct axen_softc *sc)
> @@ -238,6 +246,8 @@ axen_miibus_statchg(struct device *dev)
> int err;
> uint16_t val;
> uWord wval;
> + uint8_t linkstat = 0;
> + int qctrl;
>
> ifp = GET_IFP(sc);
> if (mii == NULL || ifp == NULL ||
> @@ -265,27 +275,49 @@ axen_miibus_statchg(struct device *dev)
> return;
>
> val = 0;
> - if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0)
> + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0) {
> val |= AXEN_MEDIUM_FDX;
> + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_TXPAUSE) != 0)
> + val |= AXEN_MEDIUM_TXFLOW_CTRL_EN;
> + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_RXPAUSE) != 0)
> + val |= AXEN_MEDIUM_RXFLOW_CTRL_EN;
> + }
>
> - val |= (AXEN_MEDIUM_RECV_EN | AXEN_MEDIUM_ALWAYS_ONE);
> - val |= (AXEN_MEDIUM_RXFLOW_CTRL_EN | AXEN_MEDIUM_TXFLOW_CTRL_EN);
> + val |= AXEN_MEDIUM_RECV_EN;
>
> + /* bulkin queue setting */
> + axen_lock_mii(sc);
> + axen_cmd(sc, AXEN_CMD_MAC_READ, 1, AXEN_USB_UPLINK, );
> + axen_unlock_mii(sc);
> +
> switch (IFM_SUBTYPE(mii->mii_media_active)) {
> case IFM_1000_T:
> val |= AXEN_MEDIUM_GIGA | AXEN_MEDIUM_EN_125MHZ;
> + if (linkstat & AXEN_USB_SS)
> + qctrl = 0;
> + else if (linkstat & AXEN_USB_HS)
> + qctrl = 1;
> + else
> + qctrl = 3;
> break;
> case IFM_100_TX:
> val |= AXEN_MEDIUM_PS;
> + if (linkstat & (AXEN_USB_SS | AXEN_USB_HS))
> + qctrl = 2;
> + else
> + qctrl = 3;
> break;
> case IFM_10_T:
> - /* doesn't need to be handled */
> + default:
> + qctrl = 3;
> break;
> }
>
> DPRINTF(("axen_miibus_statchg: val=0x%x\n", val));
> USETW(wval, val);
> axen_lock_mii(sc);
> + axen_cmd(sc, AXEN_CMD_MAC_SET_RXSR, 5, AXEN_RX_BULKIN_QCTRL,
> + _bulk_size[qctrl]);
> err = axen_cmd(sc, AXEN_CMD_MAC_WRITE2, 2, AXEN_MEDIUM_STATUS, );
> axen_unlock_mii(sc);
> if (err) {
> @@ -408,7 +440,6 @@ axen_ax88179_init(struct axen_softc *sc)
> uWord wval;
> uByte val;
> u_int16_t ctl, temp;
> - struct axen_qctrl qctrl;
>
>
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
Hi,
On 2018/07/27 09:14, Denis wrote:
Every time (after 2-3 minutes of work) ASIX Electronics USB-Ethernet
device reports:
axen0: usb errors on rx: IOERROR
axen0: usb errors on rx: IOERROR
axen0: usb errors on tx: IOERROR
axen0: watchdog timeout
axen0: usb errors on tx: IOERROR
The device hangs and must be reattached to have it working again for 2-3
minutes.
Do you want to try this patch?
-
- header: fix comments
- header: fix unused L3 type mask definition
- rxeof: Avoid allocating mbuf if checksum errors are detected.
- rxeof: Avoid loop to extract packets if pkt_count is 0.
- rxeof: Add more sanity checks.
- rxeof: Increament if_ierror in some error paths.
- qctrl: Apply queuing control parameters from FreeBSD axge(4).
- qctrl: Set qctrl in miireg_statchg dynamically, not statically.
- Use DMA buffer aligned at 64KB boundary to avoid xhci bug.
--- sys/dev/usb/if_axenreg.hFri Sep 16 22:17:07 2016
+++ sys/dev/usb/if_axenreg.hMon Jun 19 10:54:28 2017
@@ -26,8 +26,8 @@
* || ++-L3_type (1:ipv4, 0/2:ipv6)
*pkt_len(13) || ||+ ++-L4_type(0: icmp, 1: UDP, 4: TCP)
* |765|43210 76543210|7654 3210 7654 3210|
- * ||+-crc_err |+-L4_err |+-L4_CSUM_ERR
- * |+-mii_err +--L3_err +--L3_CSUM_ERR
+ * ||+-crc_err |+-L4_err |+-L4_CSUM_ERR
+ * |+-mii_err+--L3_err +--L3_CSUM_ERR
* +-drop_err
*
* ex) pkt_hdr 0x00680820
@@ -70,7 +70,7 @@
#define AXEN_RXHDR_L4_TYPE_TCP 0x4
/* L3 packet type (2bit) */
-#define AXEN_RXHDR_L3_TYPE_MASK0x0600
+#define AXEN_RXHDR_L3_TYPE_MASK0x0060
#define AXEN_RXHDR_L3_TYPE_OFFSET 5
#define AXEN_RXHDR_L3_TYPE_UNDEF 0x0
#define AXEN_RXHDR_L3_TYPE_IPV4 0x1
--- sys/dev/usb/if_axen.c.orig Tue Jun 12 15:36:59 2018
+++ sys/dev/usb/if_axen.c Sun Jul 29 01:53:43 2018
@@ -53,6 +53,7 @@
#include
#include
#include
+#include
#include
@@ -121,6 +122,13 @@ void axen_unlock_mii(struct axen_softc *sc);
void axen_ax88179_init(struct axen_softc *);
+struct axen_qctrl axen_bulk_size[] = {
+ { 7, 0x4f, 0x00, 0x12, 0xff },
+ { 7, 0x20, 0x03, 0x16, 0xff },
+ { 7, 0xae, 0x07, 0x18, 0xff },
+ { 7, 0xcc, 0x4c, 0x18, 0x08 }
+};
+
/* Get exclusive access to the MII registers */
void
axen_lock_mii(struct axen_softc *sc)
@@ -238,6 +246,8 @@ axen_miibus_statchg(struct device *dev)
int err;
uint16_tval;
uWord wval;
+ uint8_t linkstat = 0;
+ int qctrl;
ifp = GET_IFP(sc);
if (mii == NULL || ifp == NULL ||
@@ -265,27 +275,49 @@ axen_miibus_statchg(struct device *dev)
return;
val = 0;
- if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0)
+ if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0) {
val |= AXEN_MEDIUM_FDX;
+ if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_TXPAUSE) != 0)
+ val |= AXEN_MEDIUM_TXFLOW_CTRL_EN;
+ if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_RXPAUSE) != 0)
+ val |= AXEN_MEDIUM_RXFLOW_CTRL_EN;
+ }
- val |= (AXEN_MEDIUM_RECV_EN | AXEN_MEDIUM_ALWAYS_ONE);
- val |= (AXEN_MEDIUM_RXFLOW_CTRL_EN | AXEN_MEDIUM_TXFLOW_CTRL_EN);
+ val |= AXEN_MEDIUM_RECV_EN;
+ /* bulkin queue setting */
+ axen_lock_mii(sc);
+ axen_cmd(sc, AXEN_CMD_MAC_READ, 1, AXEN_USB_UPLINK, );
+ axen_unlock_mii(sc);
+
switch (IFM_SUBTYPE(mii->mii_media_active)) {
case IFM_1000_T:
val |= AXEN_MEDIUM_GIGA | AXEN_MEDIUM_EN_125MHZ;
+ if (linkstat & AXEN_USB_SS)
+ qctrl = 0;
+ else if (linkstat & AXEN_USB_HS)
+ qctrl = 1;
+ else
+ qctrl = 3;
break;
case IFM_100_TX:
val |= AXEN_MEDIUM_PS;
+ if (linkstat & (AXEN_USB_SS | AXEN_USB_HS))
+ qctrl = 2;
+ else
+ qctrl = 3;
break;
case IFM_10_T:
- /* doesn't need to be handled */
+ default:
+ qctrl = 3;
break;
}
DPRINTF(("axen_miibus_statchg: val=0x%x\n", val));
USETW(wval, val);
axen_lock_mii(sc);
+ axen_cmd(sc, AXEN_CMD_MAC_SET_RXSR, 5, AXEN_RX_BULKIN_QCTRL,
+ _bulk_size[qctrl]);
err = axen_cmd(sc, AXEN_CMD_MAC_WRITE2, 2, AXEN_MEDIUM_STATUS, );
axen_unlock_mii(sc);
if (err) {
@@ -408,7 +440,6 @@ axen_ax88179_init(struct axen_softc *sc)
uWord wval;
uByte val;
u_int16_t ctl, temp;
- struct axen_qctrl qctrl;
axen_lock_mii(sc);
@@ -471,27 +502,12 @@ axen_ax88179_init(struct axen_softc *sc)
Re: Re any XHCI issues and USB 3 superspeed (>1gbps per USB hub) support Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
On July 28, 2018 1:21 AM, Tinker wrote: > Hi Marcus, > > Thank you for following up. > > First re any XHCI bugs: .. > Second, re superspeed mode: > > stsp@ pointed out about a year ago that the XHCI driver only supports, > I think it is, 1gbps aggregate speed per USB hub presently, 5gbps aka > "superspeed". > > This might not be a very high priority, maybe except on some cheapo > ARM64:s that have only USB 3. Wait, there is mentioning of superspeed in xhci.c . https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/xhci.c?rev=1.87=text/x-cvsweb-markup Also xhci(4) says all since 2014 that "xHCI controllers support all USB 3.0, 2.0 and 1.x device speeds.". http://man.openbsd.org/xhci https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/share/man/man4/xhci.4 This shows that there is something I have misunderstood about XHCI's speed characteristics, I wonder what. Natural thing would be to ask stsp. Tinker
Re any XHCI issues and USB 3 superspeed (>1gbps per USB hub) support Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
Hi Marcus, Thank you for following up. First re any XHCI bugs: 1. The primary issue I have had is that when I evaluated XHCI around June last year, when connected to a USB 3 (XHCI) port, on 20-30% of boots, my USB NIC would not be automatically detected. However, if after the boot completed I would detach and reattach the USB NIC, it would be detected as it should. USB 2 has worked perfectly for me all the time though. This might have been fixed, I haven't tracked XHCI development recently. My previous reports, please refer to these for details: https://marc.info/?t=14963620671=1=2 https://marc.info/?t=14964072951=1=2 https://marc.info/?l=openbsd-misc=149658807922576=2 I based the understanding that XHCI was not perfectly stable on a comment from mpi@ 2017-08-08 last year he emailed me off-list > I didn't do any work on xhci(4) [..] The driver has many small issues > that should be fixed as well. Also regarding the error he responded off-list, just for reference: > Most of the drivers have a debug define. In the case of axen(4) > compiling a kernel with AXEN_DEBUG should help. > > If you wan to fix xhci(4) problems, there's a XHCI_DEBUG switch. > > Randomly testing drivers/host controllers wont help. Some XHCI > controllers might expose more bugs than others. > > You are running in a lot of bugs because nobody have the time to fix > them. Sending emails to misc@ wont fix the bugs. .. >> I learned today that OpenBSD does not implement USB3 fully, >> specifically it doesn't implement the 5gbps SuperSpeed mode, but >> only 1gbps. > > This is irrelevant to the error above. > >> I picture that this could have been because that interface for a split >> second consumed the whole 1gbps frame and then attempting to push just a >> little bit more, and there was some data loss that ended up confusing the >> cdce driver so it (for practical purposes) crashed. > > It could be anything. If you're sure it's an xhci(4) problem, because > you tried the device on ehci(4) and it works, did you try enabling > XHCI_DEBUG? > >> Too bad it doesn't recover and get online again by itself. > > You can fix the watchdog functions, look at how other drivers do it. > >> This is on a patched 6.0, someday I should try getting ureN devices on 6.1. > > This won't fix bugs. > >> Meanwhile I guess that this crash situation should be remedied simply by >> using the NIC:s' USB2 ports only instead. > > So it's an xhci(4) problem? Could you submit a bug report with a dmesg > of a kernel compiled with XHCI_DEBUG and exposing the problems above > motioned? This was on an Asrock motherboard with a Xeon E3 and an Intel C226 chipset. The malbehavior could be because of specifics pertaining to my particular USB controller of course. 2. I also did have one experience with one or a few system freezes, https://marc.info/?t=14960163472=1=2 . This was with the Axen driver which is known to be unstable, on XHCI. This freeze could mean anything I guess. I would be glad to order one or a couple Axen:s to anyone who wants to have a look! Second, re superspeed mode: stsp@ pointed out about a year ago that the XHCI driver only supports, I think it is, 1gbps aggregate speed per USB hub presently, 5gbps aka "superspeed". This might not be a very high priority, maybe except on some cheapo ARM64:s that have only USB 3. Thanks, Tinker On July 27, 2018 10:53 PM, Marcus MERIGHI wrote: > t1...@protonmail.ch (Tinker), 2018.07.27 (Fri) 12:17 (CEST): > > > (Also note that the USB 3 stack separately is unstable, and maybe > > For the archives: > > That statement is wrong, unless all the dozens of terabytes I've moved > over xhci(4) are broken now. > > Do you mean the isochronous transfer thing? CVS log says: ..
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
t1...@protonmail.ch (Tinker), 2018.07.27 (Fri) 12:17 (CEST): > (Also note that the USB 3 stack separately is unstable, and maybe For the archives: That statement is wrong, unless all the dozens of terabytes I've moved over xhci(4) are broken now. Do you mean the isochronous transfer thing? CVS log says: RCS file: /cvs/src/sys/dev/usb/xhci.c,v revision 1.77 date: 2017/09/08 10:25:19; author: stsp; state: Exp; lines: +202 -25; commitid: 6181T4xfBI8wUv3E; Add support for isochronous transfers to xhci(4). This is just a step forward which allows further progress to happen in-tree. The isochronous code path remains disabled for now. Playing audio over xhci(4) does not work properly yet, and I haven't even tested video input. Based on a work-in-progress diff by mpi@ from 2015. ok mpi@ revision 1.82 date: 2018/04/27 13:25:08; author: mpi; state: Exp; lines: +72 -19; commitid : qNZkEhEejAdtaRlW; Introduce an helper function to extract endpoint's max burst value. Use this helper to calculate the Transfer Burst Count (TBC) and Transfer Last Burst Packet Count (TLBPC) required for isochronous support. Note that SS companion descriptors are still not read. While here print the ETE and IST values in debug mode. Marcus
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
Denis, That axen is broken is known from before. See https://marc.info/?t=14960163472=1=2 https://marc.info/?t=14914106181=1=2 I requested Yojiro to fix the driver but afaik he has not done anything. AFAIK the Axen hardware is stable so it's a driver problem indeed. Overall I have a positive impression of Axen, it's designed and made in Taiwan. I've been running the Realtek 8153 on the CDCE driver and this has been stable, but performance has been 100mbps. Didn't try running the 8153 on the URE driver yet, may do later. (Also note that the USB 3 stack separately is unstable, and maybe also only supports the 1gbps mode, not 5gpbs superspeed.) Tinker ‐‐‐ Original Message ‐‐‐ On July 27, 2018 5:14 PM, Denis wrote: > Every time (after 2-3 minutes of work) ASIX Electronics USB-Ethernet > device reports: > > axen0: usb errors on rx: IOERROR > axen0: usb errors on rx: IOERROR > axen0: usb errors on tx: IOERROR > axen0: watchdog timeout > axen0: usb errors on tx: IOERROR > > The device hangs and must be reattached to have it working again for 2-3 > minutes. > > Tested on AMD and Intel platforms > > Intended to work on AMD GX-420CA SOC with Radeon(tm) HD Graphics with > dmesg below > > --- > > OpenBSD 6.3 (GENERIC.MP) #107: Sat Mar 24 14:21:59 MDT 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 7964327936 (7595MB) > avail mem = 7715876864 (7358MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0840 (38 entries) > bios0: vendor Phoenix Technologies Ltd. version "SBCFP4_3.0.0.312_11 > X64" date 09/21/2014 > bios0: CompuLab fit-PC4 > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP HPET APIC MCFG FPDT UEFI POAT BATB SSDT SSDT UEFI > acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP2(S4) GPP3(S4) GFX_(S4) > XHC0(S4) OHC1(S4) EHC1(S4) OHC2(S4) EHC2(S4) SBAZ(S4) UAR1(S3) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpihpet0 at acpi0: 14318180 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD GX-420CA SOC with Radeon(tm) HD Graphics, 1996.49 MHz > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1 > cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB > 64b/line 16-way L2 cache > cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative > acpihpet0: recalibrated TSC frequency 1996262805 Hz > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: AMD GX-420CA SOC with Radeon(tm) HD Graphics, 1996.26 MHz > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1 > cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB > 64b/line 16-way L2 cache > cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 2 (application processor) > cpu2: AMD GX-420CA SOC with Radeon(tm) HD Graphics, 1996.26 MHz > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1 > cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB > 64b/line 16-way L2 cache > cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 3 (application processor) > cpu3: AMD GX-420CA SOC with Radeon(tm) HD Graphics, 1996.26 MHz > cpu3: >
