Re: svn commit: r239214 - in head/sys: dev/usb dev/usb/controller sys
On Monday 20 August 2012 23:09:37 Ian Lepore wrote: On Mon, 2012-08-20 at 13:55 -0700, Adrian Chadd wrote: I have a report that AR71XX (MIPS) USB broke with this change. Thanks, Adrian Hi Ian, Have you figured out the root cause for this? --HPS ___ 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-unsubscr...@freebsd.org
Re: svn commit: r239214 - in head/sys: dev/usb dev/usb/controller sys
I have a report that AR71XX (MIPS) USB broke with this change. Hans, would you mind reverting it until we figure out what's going on in the non-intel USB world? Thanks, Adrian On 19 August 2012 05:15, Hans Petter Selasky hans.petter.sela...@bitfrost.no wrote: Hi, What exactly is the driver the USB mass storage device is attached to? And the problem is the same using the latest FreeBSD version from -current? You are certain that all parts of the kernel were rebuilt? And you are certain that it has nothing to do with the FreeBSD version bump which is also part of this change? Probably we should move this thread to -current @ --HPS -Original message- From: Andrew Turner and...@fubar.geek.nz Sent: Sun 19-08-2012 10:27 Subject: Re: svn commit: r239214 - in head/sys: dev/usb dev/usb/controller sys To: Hans Petter Selasky hans.petter.sela...@bitfrost.no; CC: Hans Petter Selasky hsela...@freebsd.org; svn-src-h...@freebsd.org; svn-src-all@freebsd.org; src-committ...@freebsd.org; On Sun, 19 Aug 2012 09:39:11 +0200 Hans Petter Selasky hans.petter.sela...@bitfrost.no wrote: Hi, Have you stepped the versions? I did a binary search of the commits to find the revision that caused the issue. Are you sure it is exactly this commit? I built with r239213 and the problem went away, when I built with r239214 it appeared again. Andrew ___ 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-unsubscr...@freebsd.org
Re: svn commit: r239214 - in head/sys: dev/usb dev/usb/controller sys
On Mon, 2012-08-20 at 13:55 -0700, Adrian Chadd wrote: I have a report that AR71XX (MIPS) USB broke with this change. Hans, would you mind reverting it until we figure out what's going on in the non-intel USB world? Thanks, Adrian It appears that the change in structure sizes has resulted in things shuffling around in memory in a way that triggers a partial cacheline flush bug in the busdma routines for ARM (and I guess for MIPS too). I'm chasing the actual bug in the ARM code, since it's now 100% reproducible. I'm hoping it's the concrete proof for a bug I've long thought was possible in theory. In the meantime, a quick and easy way to work around the problem is to add to your kernel config: option USB_HOST_ALIGN=32 # data cache line size on your platform Since it appears (at least until some evidence points elsewhere) that the problem is in the busdma code for architectures with VIVT caches, I'm not sure reverting the usb changes would be the right move. Avoiding an MFC until we know more might be a good idea, though. -- Ian ___ 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-unsubscr...@freebsd.org
RE: svn commit: r239214 - in head/sys: dev/usb dev/usb/controller sys
Hi, Have you stepped the versions? Are you sure it is exactly this commit? --HPS -Original message- From:Andrew Turner and...@fubar.geek.nz Sent:Sun 19-08-2012 05:01 Subject:Re: svn commit: r239214 - in head/sys: dev/usb dev/usb/controller sys To:Hans Petter Selasky hsela...@freebsd.org; CC:src-committ...@freebsd.org; svn-src-all@freebsd.org; svn-src-h...@freebsd.org; Hello, This commit causes issues for me on my AT91 board. I get messages similar to the following: (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 5f d1 a0 0 0 1d 0 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 0 0 0 7 e0 0 0 8 0 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command Other people are getting similar messages on different ARM cpus. Andrew ___ 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-unsubscr...@freebsd.org
Re: svn commit: r239214 - in head/sys: dev/usb dev/usb/controller sys
On Sun, 19 Aug 2012 09:39:11 +0200 Hans Petter Selasky hans.petter.sela...@bitfrost.no wrote: Hi, Have you stepped the versions? I did a binary search of the commits to find the revision that caused the issue. Are you sure it is exactly this commit? I built with r239213 and the problem went away, when I built with r239214 it appeared again. Andrew ___ 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-unsubscr...@freebsd.org
Re: svn commit: r239214 - in head/sys: dev/usb dev/usb/controller sys
Hello, This commit causes issues for me on my AT91 board. I get messages similar to the following: (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 5f d1 a0 0 0 1d 0 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 0 0 0 7 e0 0 0 8 0 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command Other people are getting similar messages on different ARM cpus. Andrew ___ 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-unsubscr...@freebsd.org
Re: svn commit: r239214 - in head/sys: dev/usb dev/usb/controller sys
On Sun, 2012-08-12 at 17:53 +, Hans Petter Selasky wrote: Author: hselasky Date: Sun Aug 12 17:53:06 2012 New Revision: 239214 URL: http://svn.freebsd.org/changeset/base/239214 Log: Add support for the so-called streams feature of BULK endpoints in SUPER-speed mode, USB 3.0. [...] All USB drivers should be re-compiled after this change. When this is merged, is there a way to do this without requiring all drivers to be recompiled? If not, it sounds like this (and indeed 239179) may not be merge candidates :( Gavin -- Gavin Atkinson FreeBSD committer and bugmeister GPG: A093262B (313A A79F 697D 3A5C 216A EDF5 935D EF44 A093 262B) ___ 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-unsubscr...@freebsd.org
Re: svn commit: r239214 - in head/sys: dev/usb dev/usb/controller sys
On Monday 13 August 2012 19:09:41 Gavin Atkinson wrote: On Sun, 2012-08-12 at 17:53 +, Hans Petter Selasky wrote: Author: hselasky Date: Sun Aug 12 17:53:06 2012 New Revision: 239214 URL: http://svn.freebsd.org/changeset/base/239214 Log: Add support for the so-called streams feature of BULK endpoints in SUPER-speed mode, USB 3.0. [...] All USB drivers should be re-compiled after this change. When this is merged, is there a way to do this without requiring all drivers to be recompiled? If not, it sounds like this (and indeed 239179) may not be merge candidates :( Gavin Hi, If the USB drivers do not do anything special, like accessing the changed structures, then they should be fine. Please let me know what you think. I don't need to merge this 9-stable, if you think it will break something. --HPS ___ 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-unsubscr...@freebsd.org
svn commit: r239214 - in head/sys: dev/usb dev/usb/controller sys
Author: hselasky
Date: Sun Aug 12 17:53:06 2012
New Revision: 239214
URL: http://svn.freebsd.org/changeset/base/239214
Log:
Add support for the so-called streams feature of BULK endpoints
in SUPER-speed mode, USB 3.0.
This feature has not been tested yet, due to lack of hardware.
This feature is useful when implementing protocols like UASP,
USB attached SCSI which promises higher USB mass storage throughput.
This patch also implements support for hardware processing of endpoints
for increased performance. The switching to hardware processing
of an endpoint is done via a callback to the USB controller driver. The
stream feature is implemented like a variant of a hardware USB protocol.
USB controller drivers implementing device mode needs to be updated to
implement the new xfer_stall USB controller method and remove the
xfer argument from the set_stall method.
The API's toward existing USB drivers are preserved. To setup a USB transfer
in stream mode, set the stream_id field of the USB config structure to
the desired value.
The maximum number of BULK streams is currently hardcoded and limited to 8
via a define in usb_freebsd.h.
All USB drivers should be re-compiled after this change.
LibUSB will be updated next week to support streams mode. A new IOCTL to
setup BULK streams as already been implemented. The ugen device nodes
currently only supports stream ID zero.
The FreeBSD version has been bumped.
MFC after:2 weeks
Modified:
head/sys/dev/usb/controller/at91dci.c
head/sys/dev/usb/controller/atmegadci.c
head/sys/dev/usb/controller/avr32dci.c
head/sys/dev/usb/controller/dwc_otg.c
head/sys/dev/usb/controller/musb_otg.c
head/sys/dev/usb/controller/uss820dci.c
head/sys/dev/usb/controller/xhci.c
head/sys/dev/usb/controller/xhci.h
head/sys/dev/usb/usb.h
head/sys/dev/usb/usb_controller.h
head/sys/dev/usb/usb_core.h
head/sys/dev/usb/usb_debug.c
head/sys/dev/usb/usb_device.c
head/sys/dev/usb/usb_freebsd.h
head/sys/dev/usb/usb_generic.c
head/sys/dev/usb/usb_hub.c
head/sys/dev/usb/usb_ioctl.h
head/sys/dev/usb/usb_request.c
head/sys/dev/usb/usb_transfer.c
head/sys/dev/usb/usbdi.h
head/sys/sys/param.h
Modified: head/sys/dev/usb/controller/at91dci.c
==
--- head/sys/dev/usb/controller/at91dci.c Sun Aug 12 17:01:07 2012
(r239213)
+++ head/sys/dev/usb/controller/at91dci.c Sun Aug 12 17:53:06 2012
(r239214)
@@ -1226,7 +1226,14 @@ at91dci_device_done(struct usb_xfer *xfe
}
static void
-at91dci_set_stall(struct usb_device *udev, struct usb_xfer *xfer,
+at91dci_xfer_stall(struct usb_xfer *xfer)
+{
+ USB_BUS_LOCK_ASSERT(udev-bus, MA_OWNED);
+ at91dci_device_done(xfer, USB_ERR_STALLED);
+}
+
+static void
+at91dci_set_stall(struct usb_device *udev,
struct usb_endpoint *ep, uint8_t *did_stall)
{
struct at91dci_softc *sc;
@@ -1237,10 +1244,6 @@ at91dci_set_stall(struct usb_device *ude
DPRINTFN(5, endpoint=%p\n, ep);
- if (xfer) {
- /* cancel any ongoing transfers */
- at91dci_device_done(xfer, USB_ERR_STALLED);
- }
/* set FORCESTALL */
sc = AT9100_DCI_BUS2SC(udev-bus);
csr_reg = (ep-edesc-bEndpointAddress UE_ADDR);
@@ -2332,6 +2335,7 @@ struct usb_bus_methods at91dci_bus_metho
.xfer_unsetup = at91dci_xfer_unsetup,
.get_hw_ep_profile = at91dci_get_hw_ep_profile,
.set_stall = at91dci_set_stall,
+ .xfer_stall = at91dci_xfer_stall,
.clear_stall = at91dci_clear_stall,
.roothub_exec = at91dci_roothub_exec,
.xfer_poll = at91dci_do_poll,
Modified: head/sys/dev/usb/controller/atmegadci.c
==
--- head/sys/dev/usb/controller/atmegadci.c Sun Aug 12 17:01:07 2012
(r239213)
+++ head/sys/dev/usb/controller/atmegadci.c Sun Aug 12 17:53:06 2012
(r239214)
@@ -1113,7 +1113,13 @@ atmegadci_device_done(struct usb_xfer *x
}
static void
-atmegadci_set_stall(struct usb_device *udev, struct usb_xfer *xfer,
+atmegadci_xfer_stall(struct usb_xfer *xfer)
+{
+ atmegadci_device_done(xfer, USB_ERR_STALLED);
+}
+
+static void
+atmegadci_set_stall(struct usb_device *udev,
struct usb_endpoint *ep, uint8_t *did_stall)
{
struct atmegadci_softc *sc;
@@ -1123,10 +1129,6 @@ atmegadci_set_stall(struct usb_device *u
DPRINTFN(5, endpoint=%p\n, ep);
- if (xfer) {
- /* cancel any ongoing transfers */
- atmegadci_device_done(xfer, USB_ERR_STALLED);
- }
sc = ATMEGA_BUS2SC(udev-bus);
/* get endpoint number */
ep_no = (ep-edesc-bEndpointAddress UE_ADDR);
@@ -2151,6 +2153,7 @@ struct usb_bus_methods atmegadci_bus_met
.xfer_setup = atmegadci_xfer_setup,
.xfer_unsetup =
