axen Ethernet device errors on both USB3.0 and USB2.0 ports
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: 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 cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins , remapped to apid 4 ioapic1 at mainbus0: apid 5 pa 0xfec01000, version 21, 32 pins , remapped to apid 5 acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (GPP0) acpiprt2 at acpi0: bus -1 (GPP1) acpiprt3 at acpi0: bus 4 (GPP2) acpiprt4 at acpi0: bus 5 (GPP3) acpiprt5 at acpi0: bus 1 (GFX_) acpicpu0 at acpi0: C2(0@400 io@0x841), C1(@1 halt!), PSS acpicpu1 at acpi0: C2(0@400 io@0x841), C1(@1 halt!), PSS acpicpu2 at acpi0: C2(0@400 io@0x841), C1(@1 halt!), PSS acpicpu3 at acpi0: C2(0@400 io@0x841), C1(@1 halt!), PSS acpibtn0 at acpi0: PWRB "PNP0A05" at acpi0 not configured acpivideo0 at acpi0: VGA_ cpu0: 1996 MHz: speed
Re: AR9271 athn0: could not load firmware on OpenBSD 6.3 amd64
There is no any external hub or cable between AR9271 usb stick. I attach it directly to AMD GX-420CA SOC with Radeon(tm) HD Graphics PC. Firmware does not load when it attached to any of USB2.0 ports. But when it attached to USB3.0 AR9271 works without any errors. On 4/5/2018 6:09 PM, Stefan Sperling wrote: > On Thu, Apr 05, 2018 at 05:30:25PM +0300, Denis wrote: >> 1. AR9271 USB stick has been connected to OpenBSD 6.3 amd64 >> 2. # fw_update >> 3. # ls /etc/firmware | grep athn >> athn-ar7010 >> athn-ar7010-11 >> athn-ar9271 >> athn-license >> athn-open-ar7010 >> athn-open-ar9271 >> athn-open-license >> >> After reconnecting AR9271 >> athn0: could not load firmware > > I don't know why the firmware doesn't load for you. > It all works fine for me, with both AR9271 devices and AR7010 devices. > > There is a known issue which looks like this device does not power up > properly on some machines, and in some configurations, for example > when it is plugged behind a USB 2.0 hub. > This results in a failure to load the firmware but it the underlying > issue is a different problem which nobody has figured out yet. > It could be a bug in our USB stack. > > However, this is inconsistent with your observation that it worked > in 6.2. It sounds like nothing else changed? > >> When I remove athn-open-* firmware files from /etc/firmware >> athn0: failed loadfirmware of file athn-open-ar9271 (error 2) >> athn0: could not load firmware >> >> In OpenBSD 6.2 amd64 /etc/firmware contains only athn-ar7010, >> athn-ar7010-11, and ar9271. The USB stick works with it. > > Is this 6.2 install on the same machine, or on a different machine? > If it's a different machine, could you try 6.3 on the same machine > where you tested 6.2? > >> I think it could be working again if I load non athn-open-* versions of >> firmware provided. >> >> My question is how to load non open version (athn-ar9271) of the athn >> firmware to have AR9271 working? > > You cannot. > The driver in 6.3 does not support the old closed source firmware > anymore. It only supports the open firmware. > > It's unfortunate that this change broke it for you, but I cannot > explain why. When this change was made about 2 months ago I did > not get any negative reports. > See https://marc.info/?l=openbsd-tech&m=151769894925027&w=2 > >> athn0: failed error message has a typo 'loadfirmware' without a space. > > That's intentional. It refers to the function loadfirmware(9): > http://man.openbsd.org/loadfirmware >
Re: AR9271 athn0: could not load firmware on OpenBSD 6.3 amd64
On Fri, 27 Jul 2018 12:22:08 +0300 > There is no any external hub or cable between AR9271 usb stick. I > attach it directly to AMD GX-420CA SOC with Radeon(tm) HD Graphics > PC. Firmware does not load when it attached to any of USB2.0 ports. > But when it attached to USB3.0 AR9271 works without any errors. USB3 provides more current than USB2, so this may make sense with the current theory of some USB2 boards not supplying enough power for these devices. USB has to protect against user insertion, damaged ports etc. so surges are filtered more so than required for USB via pci-ex. I wonder if the firmware loading speed can be dialed down so that less power is required (perhaps it saves memory by verifying as received) or more likely the issue occurs after upload completion? Is the open firmware a different size or sets different power settings? Are any power affecting settings available before firmware upload? If the power usage is close to the limit then it may cause micro reset/failure a varying percentage of the time. Sorry if all this has already been considered.
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&r=1&w=2 https://marc.info/?t=14914106181&r=1&w=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
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 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&r=1&w=2 https://marc.info/?t=14964072951&r=1&w=2 https://marc.info/?l=openbsd-misc&m=149658807922576&w=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&r=1&w=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: 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&content-type=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
