Audio routed to ThinkPad X120e speakers dies after a minute
>Synopsis: Audio routed to ThinkPad X120e speakers dies after a minute >Environment: System : OpenBSD 6.4 Details : OpenBSD 6.4-beta (GENERIC.MP) #208: Mon Aug 13 13:13:53 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: I have a problem I've been scratching my head on for some time. Hopefully someone can help. On my ThinkPad X120e, when audio is sent to the laptop speakers, it will work for about a minute before suddenly cutting out. If I power cycle the machine or put it to sleep with zzz and wake it up, I get another minute or so of audio playback from the speakers and then it will cut out again. Audio routed to the headphone jack always works and does not suffer from this issue. >How-To-Repeat: Turn on machine, play some audio from the laptop speakers. >Fix: Don't know. dmesg: OpenBSD 6.4-beta (GENERIC.MP) #208: Mon Aug 13 13:13:53 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8145928192 (7768MB) avail mem = 7889858560 (7524MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf9ba0 (60 entries) bios0: vendor LENOVO version "8FET33WW (1.17 )" date 11/07/2012 bios0: LENOVO 05962PU acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC ELIC HPET APIC MCFG UEFI UEFI SSDT SSDT UEFI acpi0: wakeup devices PB4_(S4) PB5_(S4) PB6_(S4) PB7_(S4) OHC1(S3) OHC2(S3) EHC2(S3) OHC3(S3) EHC3(S3) OHC4(S3) SBAZ(S4) GEC_(S4) P2P_(S5) SPB0(S4) SPB1(S4) SPB2(S4) [...] 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 E-350 Processor, 1597.55 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,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD E-350 Processor, 1596.60 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,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins , remapped to apid 2 acpimcfg0 at acpi0 addr 0xf800, bus 0-31 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PB4_) acpiprt2 at acpi0: bus -1 (PB5_) acpiprt3 at acpi0: bus 1 (PB6_) acpiprt4 at acpi0: bus -1 (PB7_) acpiprt5 at acpi0: bus 2 (P2P_) acpiprt6 at acpi0: bus 3 (SPB0) acpiprt7 at acpi0: bus 4 (SPB1) acpiprt8 at acpi0: bus -1 (SPB2) acpiprt9 at acpi0: bus -1 (SPB3) acpiec0 at acpi0 acpicpu0 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS acpicpu1 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS acpitz0 at acpi0: critical temperature is 92 degC acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: SLPB acpicmos0 at acpi0 "LEN0017" at acpi0 not configured acpithinkpad0 at acpi0 acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT1 serial type LION acpibtn2 at acpi0: LID_ "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured acpivideo0 at acpi0: VGA_ acpivideo1 at acpi0: VGA_ cpu0: 1597 MHz: speeds: 1600 1280 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD AMD64 14h Host" rev 0x00 radeondrm0 at pci0 dev 1 function 0 "ATI Radeon HD 6310" rev 0x00 drm0 at radeondrm0 radeondrm0: msi azalia0 at pci0 dev 1 function 1 "ATI Radeon HD 6310 HD Audio" rev 0x00: msi azalia0: no supported codecs ppb0 at pci0 dev 6 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi pci1 at ppb0 bus 1 1:0:0: mem address conflict 0xfffe/0x2 re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x03: RTL8168D/8111D (0x2800), msi, address e8:9a:8f:66:16:dc rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 2 ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x00: apic 2 int 19, AHCI 1.2 ahci0: port 0: 3.0Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed naa.5707c181004e260e sd0: 122104MB, 512 bytes/sector, 250069680 sectors, thin ohci0 at pci0 dev 18 function 0 "ATI SB700 USB" rev 0x00: apic 2 int
Re: dhclient cannot get a lease until next reboot
I understand the situation, but I really do not have the time right now for this. I have no choice but to plug the cable everytime until it gets fixed or I have some spare time. Eventually though I am planning to use -current for all my projects. 2018/08/19 20:27、Sebastian Benoit のメール: > Theo de Raadt(dera...@openbsd.org) on 2018.08.15 21:29:20 -0600: >> A number of workarounds for that specific ethernet chip were >> commited after 6.3. It has some severe errata... > > kawashima_ja...@yahoo.co.jp(kawashima_ja...@yahoo.co.jp) on 2018.08.16 > 12:59:25 +0900: >> Thank you for your answer. It is just a laptop so I will wait for 6.4. > > Please try and install -current. You can't expect things to just magically > work in 6.4. Without testing -current on your hardware and sending bug > reports (or success reports) we just don't know if your problem has been > fixed.
Re: dhclient cannot get a lease until next reboot
Theo de Raadt(dera...@openbsd.org) on 2018.08.15 21:29:20 -0600: > A number of workarounds for that specific ethernet chip were > commited after 6.3. It has some severe errata... kawashima_ja...@yahoo.co.jp(kawashima_ja...@yahoo.co.jp) on 2018.08.16 12:59:25 +0900: > Thank you for your answer. It is just a laptop so I will wait for 6.4. Please try and install -current. You can't expect things to just magically work in 6.4. Without testing -current on your hardware and sending bug reports (or success reports) we just don't know if your problem has been fixed.
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 |=
