From nobody@FreeBSD.org Thu Nov 26 02:59:55 2009 Return-Path: Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E3E91065670 for ; Thu, 26 Nov 2009 02:59:55 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 7D2038FC12 for ; Thu, 26 Nov 2009 02:59:55 +0000 (UTC) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id nAQ2xtVw000959 for ; Thu, 26 Nov 2009 02:59:55 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id nAQ2xtXf000958; Thu, 26 Nov 2009 02:59:55 GMT (envelope-from nobody) Message-Id: <200911260259.nAQ2xtXf000958@www.freebsd.org> Date: Thu, 26 Nov 2009 02:59:55 GMT From: sub mesa To: freebsd-gnats-submit@FreeBSD.org Subject: axe(4) USB gigabit ethernet hangs after short period of traffic X-Send-Pr-Version: www-3.1 X-GNATS-Notify: >Number: 140883 >Category: usb >Synopsis: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic >Confidential: no >Severity: serious >Priority: medium >Responsible: yongari >State: closed >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Nov 26 03:00:11 UTC 2009 >Closed-Date: Fri Jan 14 23:07:32 UTC 2011 >Last-Modified: Fri Jan 14 23:07:32 UTC 2011 >Originator: sub mesa >Release: FreeBSD 8.0-RELEASE i386 >Organization: >Environment: FreeBSD gut 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Wed Nov 25 14:30:17 CET 2009 xor@xor:/usr/obj/usr/src/sys/XOR i386 >Description: I own a USB gigabit ethernet adapter with ASIX Electronics AX88178 chip supported by the axe(4) driver in FreeBSD 8.0. It works, but it 'freezes' or 'hangs' after some traffic, like downloading at ~50Mbps for 5-10 minutes will cause the device to freeze. This has been happening since a long time on 8.0, ever since i bought the device and was running one of the early beta's. Upgrading to the final release of 8.0 did not resolve the issue. Googling on the problem i found this mailinglist thread: http://lists.freebsd.org/pipermail/freebsd-current/2009-April/005738.html However, there doesn't seem to be a single conclusion. Even though my product ("Belkin F5D5055") seems to be supported according to the axe(4) manpage, it doesn't get detected as such, rather with a vendor id. Quoting dmesg output: axe0: on usbus4 axe0: PHYADDR 0xe0:0x01 miibus1: on axe0 ue0: on axe0 May i suggest removing the Belkin F5D5055 from the supported devices list in the axe(4) manpage, until a fix has been committed? I specifically bought the device believing it would work since it was explicitly listed in the manpage. As of 8.0, it doesn't even get detected by name. It is of course possible my device is of a different revision. I would be happy to try any patches. Also see: http://forums.freebsd.org/showthread.php?t=8661 >How-To-Repeat: Connect axe(4) gigabit ethernet device Send/receive packets using the ueX ethernet device Device will stop receiving/transmitting packets after a short while >Fix: Workaround: re-plug device or use usbreset command. No fix known. >Release-Note: >Audit-Trail: From: Hans Petter Selasky To: freebsd-usb@freebsd.org Cc: sub mesa , freebsd-gnats-submit@freebsd.org Subject: Re: usb/140883: axe(4) USB gigabit ethernet hangs after short period of traffic Date: Thu, 26 Nov 2009 09:32:43 +0100 You can try enabling debugging: sysctl hw.usb.axe.debug=15 --HPS State-Changed-From-To: open->feedback State-Changed-By: gavin State-Changed-When: Sat Nov 28 22:43:41 UTC 2009 State-Changed-Why: Submitter has been asked for feedback http://www.freebsd.org/cgi/query-pr.cgi?pr=140883 From: Brett Glass To: bug-followup@FreeBSD.org Cc: sub.mesa@gmail.com Subject: Re: usb/140883: [axe] USB gigabit ethernet hangs after short period of traffic Date: Sat, 28 Nov 2009 19:04:49 -0700 The reason why the vendor name and device name is not appearing is that the USB_VERBOSE option was not included in the configuration of the 8.0-RELEASE GENERIC kernel. The USB_VERBOSE option should be included in GENERIC. Otherwise, any USB device whose driver follows the proper coding convention -- that is, placing vendor and product information in /sys/usb/usbdevs rather than in the driver itself -- will not print the name of the vendor or device. The failure to print the name has nothing to do with the malfunction in the device, which may be due to overruns. (The buffer size currently allowed in the driver -- only 4K -- is extremely small.) --Brett Glass From: Jason Edwards To: bug-followup@FreeBSD.org, Pyun YongHyeon Cc: Subject: Re: usb/140883: [axe] USB gigabit ethernet hangs after short period of traffic Date: Tue, 1 Dec 2009 14:36:44 +0100 --000325558d665019be0479aad903 Content-Type: text/plain; charset=ISO-8859-1 Hello list and Pyon YongHyeon, I tried your patch, which would let axe use amphy instead of ukphy, but it doesn't seem to work; it still uses the ukphy and it still crashes. I managed to set hw.usb.axe.debug to 15 and record /var/log/messages during heavy traffic (~50 megabits). Output is below. First the dmesg after applying patch and rebuilding kernel (axe is built in the kernel) though it doesnt seem to have changed since before the patch: ------- ugen4.2: at usbus4 axe0: on usbus4 axe0: PHYADDR 0xe0:0x01 (..) miibus1: on axe0 ukphy0: PHY 1 on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto ue0: on axe0 ue0: Ethernet address: ------- debug output during heavy traffic: --- Dec 1 14:10:52 mesa kernel: axe_bulk_write_callback:870: transfer complete Dec 1 14:11:23 mesa last message repeated 493 times Dec 1 14:12:57 mesa last message repeated 2755 times (..) Dec 1 14:12:57 mesa kernel: axe_bulk_write_callback:870: transfer complete Dec 1 14:13:28 mesa last message repeated 1721 times Dec 1 14:15:29 mesa last message repeated 35874 times Dec 1 14:23:11 mesa last message repeated 557689 times Dec 1 14:23:11 mesa kernel: axe_bulk_write_callback:870: transferite_callback:870: transfer complete Dec 1 14:23:11 mesa kernel: axe_bulk_write_callback:870: transfer complete Dec 1 14:23:42 mesa last message repeated 46012 times Dec 1 14:25:43 mesa last message repeated 174082 times Dec 1 14:26:35 mesa last message repeated 76977 times Dec 1 14:26:45 mesa kernel: axe_bulk_write_callback:941: transfer error, USB_ERR_TIMEOUT Dec 1 14:26:46 mesa miniupnpd[968]: sendto(udp_notify=7, 10.0.1.1): No buffer space available Dec 1 14:26:46 mesa last message repeated 6 times Dec 1 14:26:55 mesa kernel: axe_bulk_write_callback:941: transfer error, USB_ERR_TIMEOUT Dec 1 14:27:14 mesa last message repeated 2 times Dec 1 14:27:16 mesa miniupnpd[968]: sendto(udp_notify=7, 10.0.1.1): No buffer space available Dec 1 14:27:16 mesa last message repeated 6 times Dec 1 14:27:24 mesa kernel: axe_bulk_write_callback:941: transfer error, USB_ERR_TIMEOUT Dec 1 14:27:44 mesa last message repeated 2 times Dec 1 14:27:46 mesa miniupnpd[968]: sendto(udp_notify=7, 10.0.1.1): No buffer space available Dec 1 14:27:46 mesa last message repeated 6 times Dec 1 14:27:53 mesa kernel: axe_bulk_write_callback:941: transfer error, USB_ERR_TIMEOUT Dec 1 14:28:13 mesa last message repeated 2 times Dec 1 14:28:16 mesa miniupnpd[968]: sendto(udp_notify=7, 10.0.1.1): No buffer space available Dec 1 14:28:16 mesa last message repeated 6 times Dec 1 14:28:23 mesa kernel: axe_bulk_write_callback:941: transfer error, USB_ERR_TIMEOUT Dec 1 14:28:43 mesa last message repeated 2 times Dec 1 14:28:46 mesa miniupnpd[968]: sendto(udp_notify=7, 10.0.1.1): No buffer space available Dec 1 14:28:46 mesa last message repeated 6 times Dec 1 14:28:52 mesa kernel: axe_bulk_write_callback:941: transfer error, USB_ERR_TIMEOUT Dec 1 14:29:12 mesa last message repeated 2 times Dec 1 14:29:16 mesa miniupnpd[968]: sendto(udp_notify=7, 10.0.1.1): No buffer space available Dec 1 14:29:16 mesa last message repeated 7 times Dec 1 14:29:22 mesa kernel: axe_bulk_write_callback:941: transfer error, USB_ERR_TIMEOUT Dec 1 14:30:01 mesa last message repeated 4 times Dec 1 14:30:11 mesa kernel: axe_bulk_write_callback:941: transfer error, USB_ERR_TIMEOUT Dec 1 14:30:16 mesa miniupnpd[968]: sendto(udp_notify=7, 10.0.1.1): No buffer space available Dec 1 14:30:16 mesa last message repeated 6 times Dec 1 14:30:21 mesa kernel: axe_bulk_write_callback:941: transfer error, USB_ERR_TIMEOUT Dec 1 14:30:31 mesa kernel: axe_bulk_write_callback:941: transfer error, USB_ERR_TIMEOUT Dec 1 14:30:40 mesa kernel: ue0: link state changed to DOWN Dec 1 14:30:40 mesa kernel: axe_bulk_write_callback:941: transfer error, USB_ERR_TIMEOUT --- Regards, sub --000325558d665019be0479aad903-- From: Derrick Brashear To: bug-followup@FreeBSD.org Cc: Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic Date: Tue, 20 Jul 2010 11:39:28 -0400 Happens with non-gig adapters also: axe0: on usbus2 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto axe1: on usbus2 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto USB200M v2. USB_ERR_TIMEOUT until a reset is forced after a large amount of data passes, e.g. Jul 20 01:50:38 rtr kernel: axe_bulk_write_callback: transfer error, USB_ERR_TIMEOUT Jul 20 01:50:48 rtr kernel: axe_bulk_write_callback: transfer error, USB_ERR_TIMEOUT Jul 20 01:50:57 rtr kernel: axe_bulk_write_callback: transfer error, USB_ERR_TIMEOUT Jul 20 01:51:01 rtr kernel: axe_bulk_read_callback: bulk read error, USB_ERR_CANCELLED Jul 20 01:51:01 rtr kernel: axe_bulk_write_callback: transfer error, USB_ERR_CANCELLED Jul 20 01:51:13 rtr kernel: axe_bulk_read_callback: bulk read error, USB_ERR_CANCELLED and data continues to be able to be read after writing it fails, as described in the original PR. sysctl -a|grep date kern.osreldate: 801000 -- Derrick From: Nicolas Blais To: bug-followup@FreeBSD.org, sub.mesa@gmail.com Cc: Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic Date: Tue, 26 Oct 2010 12:51:49 +0430 I'm having the same problem here with vendor 0x05ac, product 0x1402, rev 2.00/0.01 (Apple Ethernet USB Adapter). It freezes after a while. I am running a transparent squid server and the freezes also affects my bridge interface. Until I get a new PCI NIC, I have a script running from crontab every 15 minutes to reset the interface and bring the bridge back up. ############## #!/bin/sh usbconfig -u 7 -a 2 reset sleep 3 ifconfig bridge0 addm ue0 up ############## Nick. From: Derrick Brashear To: bug-followup@FreeBSD.org, sub.mesa@gmail.com Cc: Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic Date: Thu, 18 Nov 2010 09:36:50 -0500 Pyun has provided an updated driver which avoids several issues including using a too-large transmit buffer (the chipset claims only 8k) but none of the fixes worked until he disabled frame combining for transmit. With only a single packet being sent per frame (as was the case in FreeBSD 7, apparently) seems to make the issue go away. None of the cases I could use to reproduce the issue now happen. -- Derrick From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: usb/140883: commit references a PR Date: Wed, 8 Dec 2010 01:24:11 +0000 (UTC) Author: yongari Date: Wed Dec 8 01:24:05 2010 New Revision: 216284 URL: http://svn.freebsd.org/changeset/base/216284 Log: r184610 changed the way how TX frames are handled on AX88178 and AX88772 controllers. ASIX added a new feature for AX88178/AX88772 controllers which allows combining multiple TX frames into a single big frame. This was to overcome one of USB limitation where it can't generate more than 8k interrupts/sec which in turn means USB ethernet controllers can not send more than 8k packets per second. Using ASIX's feature greatly enhanced TX performance(more than 3~4 times) compared to 7.x driver. However it seems r184610 removed boundary checking for buffered frames which in turn caused instability issues under certain conditions. In addition, using ASIX's feature triggered another issue which made USB controller hang under certain conditions. Restarting ethernet controller didn't help under this hang condition and unplugging and replugging the controller was the only solution. I believe there is a silicon bug in TX frame combining feature on AX88178/AX88772 controllers. To address these issues, reintroduce the boundary checking for both AX88178 and AX88772 after copying a frame to USB buffer and do not use ASIX's multiple frame combining feature. Instead, use USB controller's multi-frame transmit capability to enhance TX performance as suggested by Hans[1]. This should fix a long standing axe(4) instability issues reported on AX88772 and AX88178 controllers. While I'm here remove unnecessary TX frame length check since upper stack always guarantee the size of a frame to be less than MCLBYTES. Special thanks to Derrick Brashear who tried numerous patches during last 4 months and waited real fix with patience. Without this enthusiastic support, patience and H/W donation I couldn't fix it since I was not able to trigger the issue on my box. Suggested by: hselasky [1] Tested by: Derrick Brashear (shadow <> gmail dot com> H/W donated by: Derrick Brashear (shadow <> gmail dot com> PR: usb/140883 Modified: head/sys/dev/usb/net/if_axe.c Modified: head/sys/dev/usb/net/if_axe.c ============================================================================== --- head/sys/dev/usb/net/if_axe.c Wed Dec 8 00:09:24 2010 (r216283) +++ head/sys/dev/usb/net/if_axe.c Wed Dec 8 01:24:05 2010 (r216284) @@ -200,7 +200,8 @@ static const struct usb_config axe_confi .type = UE_BULK, .endpoint = UE_ADDR_ANY, .direction = UE_DIR_OUT, - .bufsize = AXE_BULK_BUF_SIZE, + .frames = 16, + .bufsize = 16 * MCLBYTES, .flags = {.pipe_bof = 1,.force_short_xfer = 1,}, .callback = axe_bulk_write_callback, .timeout = 10000, /* 10 seconds */ @@ -939,7 +940,7 @@ axe_bulk_write_callback(struct usb_xfer struct ifnet *ifp = uether_getifp(&sc->sc_ue); struct usb_page_cache *pc; struct mbuf *m; - int pos; + int nframes, pos; switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: @@ -956,40 +957,34 @@ tr_setup: */ return; } - pos = 0; - pc = usbd_xfer_get_frame(xfer, 0); - - while (1) { + for (nframes = 0; nframes < 16 && + !IFQ_DRV_IS_EMPTY(&ifp->if_snd); nframes++) { IFQ_DRV_DEQUEUE(&ifp->if_snd, m); - - if (m == NULL) { - if (pos > 0) - break; /* send out data */ - return; - } - if (m->m_pkthdr.len > MCLBYTES) { - m->m_pkthdr.len = MCLBYTES; - } + if (m == NULL) + break; + usbd_xfer_set_frame_offset(xfer, nframes * MCLBYTES, + nframes); + pos = 0; + pc = usbd_xfer_get_frame(xfer, nframes); if (AXE_IS_178_FAMILY(sc)) { - hdr.len = htole16(m->m_pkthdr.len); hdr.ilen = ~hdr.len; - usbd_copy_in(pc, pos, &hdr, sizeof(hdr)); - pos += sizeof(hdr); - - /* - * NOTE: Some drivers force a short packet - * by appending a dummy header with zero - * length at then end of the USB transfer. - * This driver uses the - * USB_FORCE_SHORT_XFER flag instead. - */ + usbd_m_copy_in(pc, pos, m, 0, m->m_pkthdr.len); + pos += m->m_pkthdr.len; + if ((pos % 512) == 0) { + hdr.len = 0; + hdr.ilen = 0xffff; + usbd_copy_in(pc, pos, &hdr, + sizeof(hdr)); + pos += sizeof(hdr); + } + } else { + usbd_m_copy_in(pc, pos, m, 0, m->m_pkthdr.len); + pos += m->m_pkthdr.len; } - usbd_m_copy_in(pc, pos, m, 0, m->m_pkthdr.len); - pos += m->m_pkthdr.len; /* * XXX @@ -1010,22 +1005,16 @@ tr_setup: m_freem(m); - if (AXE_IS_178_FAMILY(sc)) { - if (pos > (AXE_BULK_BUF_SIZE - MCLBYTES - sizeof(hdr))) { - /* send out frame(s) */ - break; - } - } else { - /* send out frame */ - break; - } + /* Set frame length. */ + usbd_xfer_set_frame_len(xfer, nframes, pos); + } + if (nframes != 0) { + usbd_xfer_set_frames(xfer, nframes); + usbd_transfer_submit(xfer); + ifp->if_drv_flags |= IFF_DRV_OACTIVE; } - - usbd_xfer_set_frame_len(xfer, 0, pos); - usbd_transfer_submit(xfer); - ifp->if_drv_flags |= IFF_DRV_OACTIVE; return; - + /* NOTREACHED */ default: /* Error */ DPRINTFN(11, "transfer error, %s\n", usbd_errstr(error)); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" State-Changed-From-To: feedback->patched State-Changed-By: yongari State-Changed-When: Wed Dec 8 01:54:08 UTC 2010 State-Changed-Why: Fix committed to HEAD(r216284). Responsible-Changed-From-To: freebsd-usb->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Wed Dec 8 01:54:08 UTC 2010 Responsible-Changed-Why: Track. http://www.freebsd.org/cgi/query-pr.cgi?pr=140883 From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: usb/140883: commit references a PR Date: Fri, 14 Jan 2011 22:36:44 +0000 (UTC) Author: yongari Date: Fri Jan 14 22:36:33 2011 New Revision: 217429 URL: http://svn.freebsd.org/changeset/base/217429 Log: MFC r216284: r184610 changed the way how TX frames are handled on AX88178 and AX88772 controllers. ASIX added a new feature for AX88178/AX88772 controllers which allows combining multiple TX frames into a single big frame. This was to overcome one of USB limitation where it can't generate more than 8k interrupts/sec which in turn means USB ethernet controllers can not send more than 8k packets per second. Using ASIX's feature greatly enhanced TX performance(more than 3~4 times) compared to 7.x driver. However it seems r184610 removed boundary checking for buffered frames which in turn caused instability issues under certain conditions. In addition, using ASIX's feature triggered another issue which made USB controller hang under certain conditions. Restarting ethernet controller didn't help under this hang condition and unplugging and replugging the controller was the only solution. I believe there is a silicon bug in TX frame combining feature on AX88178/AX88772 controllers. To address these issues, reintroduce the boundary checking for both AX88178 and AX88772 after copying a frame to USB buffer and do not use ASIX's multiple frame combining feature. Instead, use USB controller's multi-frame transmit capability to enhance TX performance as suggested by Hans[1]. This should fix a long standing axe(4) instability issues reported on AX88772 and AX88178 controllers. While I'm here remove unnecessary TX frame length check since upper stack always guarantee the size of a frame to be less than MCLBYTES. Special thanks to Derrick Brashear who tried numerous patches during last 4 months and waited real fix with patience. Without this enthusiastic support, patience and H/W donation I couldn't fix it since I was not able to trigger the issue on my box. Suggested by: hselasky [1] Tested by: Derrick Brashear (shadow <> gmail dot com> H/W donated by: Derrick Brashear (shadow <> gmail dot com> PR: usb/140883 Modified: stable/8/sys/dev/usb/net/if_axe.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) Modified: stable/8/sys/dev/usb/net/if_axe.c ============================================================================== --- stable/8/sys/dev/usb/net/if_axe.c Fri Jan 14 22:33:12 2011 (r217428) +++ stable/8/sys/dev/usb/net/if_axe.c Fri Jan 14 22:36:33 2011 (r217429) @@ -200,7 +200,8 @@ static const struct usb_config axe_confi .type = UE_BULK, .endpoint = UE_ADDR_ANY, .direction = UE_DIR_OUT, - .bufsize = AXE_BULK_BUF_SIZE, + .frames = 16, + .bufsize = 16 * MCLBYTES, .flags = {.pipe_bof = 1,.force_short_xfer = 1,}, .callback = axe_bulk_write_callback, .timeout = 10000, /* 10 seconds */ @@ -939,7 +940,7 @@ axe_bulk_write_callback(struct usb_xfer struct ifnet *ifp = uether_getifp(&sc->sc_ue); struct usb_page_cache *pc; struct mbuf *m; - int pos; + int nframes, pos; switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: @@ -956,40 +957,34 @@ tr_setup: */ return; } - pos = 0; - pc = usbd_xfer_get_frame(xfer, 0); - - while (1) { + for (nframes = 0; nframes < 16 && + !IFQ_DRV_IS_EMPTY(&ifp->if_snd); nframes++) { IFQ_DRV_DEQUEUE(&ifp->if_snd, m); - - if (m == NULL) { - if (pos > 0) - break; /* send out data */ - return; - } - if (m->m_pkthdr.len > MCLBYTES) { - m->m_pkthdr.len = MCLBYTES; - } + if (m == NULL) + break; + usbd_xfer_set_frame_offset(xfer, nframes * MCLBYTES, + nframes); + pos = 0; + pc = usbd_xfer_get_frame(xfer, nframes); if (AXE_IS_178_FAMILY(sc)) { - hdr.len = htole16(m->m_pkthdr.len); hdr.ilen = ~hdr.len; - usbd_copy_in(pc, pos, &hdr, sizeof(hdr)); - pos += sizeof(hdr); - - /* - * NOTE: Some drivers force a short packet - * by appending a dummy header with zero - * length at then end of the USB transfer. - * This driver uses the - * USB_FORCE_SHORT_XFER flag instead. - */ + usbd_m_copy_in(pc, pos, m, 0, m->m_pkthdr.len); + pos += m->m_pkthdr.len; + if ((pos % 512) == 0) { + hdr.len = 0; + hdr.ilen = 0xffff; + usbd_copy_in(pc, pos, &hdr, + sizeof(hdr)); + pos += sizeof(hdr); + } + } else { + usbd_m_copy_in(pc, pos, m, 0, m->m_pkthdr.len); + pos += m->m_pkthdr.len; } - usbd_m_copy_in(pc, pos, m, 0, m->m_pkthdr.len); - pos += m->m_pkthdr.len; /* * XXX @@ -1010,22 +1005,16 @@ tr_setup: m_freem(m); - if (AXE_IS_178_FAMILY(sc)) { - if (pos > (AXE_BULK_BUF_SIZE - MCLBYTES - sizeof(hdr))) { - /* send out frame(s) */ - break; - } - } else { - /* send out frame */ - break; - } + /* Set frame length. */ + usbd_xfer_set_frame_len(xfer, nframes, pos); + } + if (nframes != 0) { + usbd_xfer_set_frames(xfer, nframes); + usbd_transfer_submit(xfer); + ifp->if_drv_flags |= IFF_DRV_OACTIVE; } - - usbd_xfer_set_frame_len(xfer, 0, pos); - usbd_transfer_submit(xfer); - ifp->if_drv_flags |= IFF_DRV_OACTIVE; return; - + /* NOTREACHED */ default: /* Error */ DPRINTFN(11, "transfer error, %s\n", usbd_errstr(error)); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" State-Changed-From-To: patched->closed State-Changed-By: yongari State-Changed-When: Fri Jan 14 23:07:10 UTC 2011 State-Changed-Why: MFC to stable/8 completed. Thanks a lot for reporting! http://www.freebsd.org/cgi/query-pr.cgi?pr=140883 >Unformatted: