Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports

2018-08-27 Thread sc dying 
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

2018-08-27 Thread sc dying 
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: 
> 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-

Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports

2018-08-23 Thread sc . dying 
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, &linkstat);
+   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,
+   &axen_bulk_size[qctrl]);
err = axen_cmd(sc, AXEN_CMD_MAC_WRITE2, 2, AXEN_MEDIUM_STATUS, &wval);
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

2018-08-19 Thread sc dying 
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

2018-08-18 Thread sc . dying 
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 */
+

Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports

2018-08-17 Thread sc dying 
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

2018-08-14 Thread sc . dying 
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 axe

Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports

2018-08-08 Thread sc dying 
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

2018-08-07 Thread sc . dying 

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, &linkstat);
+   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,
+   &axen_bulk_size[qctrl]);
err = axen_cmd(sc, AXEN_CMD_MAC_WRITE2, 2, AXEN_MEDIUM_STATUS, &wval);
axen_unlock_mii(sc);
if (err) {
@@ -408,7 +440,6 @@ axen_ax88179_init(struct axen_softc *sc)
uWord   wval;
uByte   val;

Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports

2018-08-06 Thread sc . dying 

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, &linkstat);
+   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,
+   &axen_bulk_size[qctrl]);
err = axen_cmd(sc, AXEN_CMD_MAC_WRITE2, 2, AXEN_MEDIUM_STATUS, &wval);
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

Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports

2018-07-31 Thread sc dying 
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

2018-07-29 Thread sc . dying 

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, &linkstat);
+   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,
+   &axen_bulk_size[qctrl]);
err = axen_cmd(sc, AXEN_CMD_MAC_WRITE2, 2, AXEN_MEDIUM_STATUS, &wval);
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_so