Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
On 01/12/14 07:10, Alex Goncharov wrote: The following reply was made to PR usb/185628; it has been noted by GNATS. From: Alex Goncharov alex_goncharov_...@yahoo.com To: freebsd-gnats-sub...@freebsd.org freebsd-gnats-sub...@freebsd.org, Hans Petter Selasky h...@bitfrost.no, freebsd-usb@FreeBSD.org Cc: Subject: Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321 Date: Sat, 11 Jan 2014 21:58:02 -0800 (PST) --2120775178-1643984294-1389506282=:33519 Content-Type: text/plain; charset=us-ascii ,-- On Fri, 1/10/14, Hans Petter Selasky h...@bitfrost.no wrote: ,-- On 01/10/14 12:49, Alex Goncharov wrote: Maybe; but think about the fact correlations: the fact of the two system's upgrade, two identical Seagate units, and other HDDs being non-stalled. If you are running EHCI, there has been no changes in the USB stack, Apparently, there have been; this is what causes the bogus error: r259454 | hselasky | 2013-12-16 03:51:58 -0500 (Mon, 16 Dec 2013) | 11 lines MFC r244503 and r246565: Make sure all USB drivers allocate buffer memory through the USB API and/or busdma. The following assumptions have been made: umass - buffers passed from CAM/SCSI layer are OK network - mbufs are OK. Some other nits while at it. I am attaching the code difference for the two relevant files M sys/dev/usb/storage/ustorage_fs.c M sys/dev/usb/usb_msctest.c in this change set, skipping the irrelevant 'sys/dev/usb/wlan' ones. Can this be fixed reasonably soon, please? (I miss my HDDs :) Hi, Can you do usbdump -i usbusX -s 65536 -vvv where is X is the controller unit which the seagate drive attaches to, before and after reverting patch 259454. I need to see what the difference is in the USB level, because patch 259454 should not affect the protocol data only the timing. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
The following reply was made to PR usb/185628; it has been noted by GNATS. From: Hans Petter Selasky h...@bitfrost.no To: Alex Goncharov alex_goncharov_...@yahoo.com, freebsd-usb@FreeBSD.org, freebsd-gnats-sub...@freebsd.org Cc: Subject: Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321 Date: Sun, 12 Jan 2014 09:08:27 +0100 On 01/12/14 07:10, Alex Goncharov wrote: The following reply was made to PR usb/185628; it has been noted by GNATS. From: Alex Goncharov alex_goncharov_...@yahoo.com To: freebsd-gnats-sub...@freebsd.org freebsd-gnats-sub...@freebsd.org, Hans Petter Selasky h...@bitfrost.no, freebsd-usb@FreeBSD.org Cc: Subject: Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321 Date: Sat, 11 Jan 2014 21:58:02 -0800 (PST) --2120775178-1643984294-1389506282=:33519 Content-Type: text/plain; charset=us-ascii ,-- On Fri, 1/10/14, Hans Petter Selasky h...@bitfrost.no wrote: ,-- On 01/10/14 12:49, Alex Goncharov wrote: Maybe; but think about the fact correlations: the fact of the two system's upgrade, two identical Seagate units, and other HDDs being non-stalled. If you are running EHCI, there has been no changes in the USB stack, Apparently, there have been; this is what causes the bogus error: r259454 | hselasky | 2013-12-16 03:51:58 -0500 (Mon, 16 Dec 2013) | 11 lines MFC r244503 and r246565: Make sure all USB drivers allocate buffer memory through the USB API and/or busdma. The following assumptions have been made: umass - buffers passed from CAM/SCSI layer are OK network - mbufs are OK. Some other nits while at it. I am attaching the code difference for the two relevant files M sys/dev/usb/storage/ustorage_fs.c M sys/dev/usb/usb_msctest.c in this change set, skipping the irrelevant 'sys/dev/usb/wlan' ones. Can this be fixed reasonably soon, please? (I miss my HDDs :) Hi, Can you do usbdump -i usbusX -s 65536 -vvv where is X is the controller unit which the seagate drive attaches to, before and after reverting patch 259454. I need to see what the difference is in the USB level, because patch 259454 should not affect the protocol data only the timing. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
Step 2 is here -- the stall with the 2014-01-05 (r260321) kernel. The attached log covers: the attach-detach-attach-detach sequence. On Sun, 1/12/14, Alex Goncharov alex_goncharov_...@yahoo.com wrote: Subject: Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321 To: Hans Petter Selasky h...@bitfrost.no, freebsd-usb@FreeBSD.org freebsd-usb@FreeBSD.org, freebsd-gnats-sub...@freebsd.org freebsd-gnats-sub...@freebsd.org Date: Sunday, January 12, 2014, 12:02 PM I'll do it slightly differently first -- it'll be easier for me this way. I'll do it differently if you don't find what you are looking for here. Step 1: I booted into kernel-2013-12-16/kernel -- r259449. I can see and mount /dev/da0 when I connect the Seagate HDD. I am attaching the lo of the usbdump here, including the event of 'mount' and 'umount'. Next, I'll reboot into the current (2014-01-05) kernel and will collect similar information. It'll be in the next message. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
On 01/12/14 18:20, Alex Goncharov wrote: The following reply was made to PR usb/185628; it has been noted by GNATS. Hi, Thank you for the logs. I see now what is going on. Your Seagate USB enclosures are crashing hard upon a zero length command block :-( And cannot recover afterwards. The others are not. It is related to some patches which I forgot to MFC to 9-stable which are already in 10 and 11, and not in 8-stable. Can you svn up to 9-stable and try again after this: http://svnweb.freebsd.org/changeset/base/260575 Thank you! --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/185628: commit references a PR
The following reply was made to PR usb/185628; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: usb/185628: commit references a PR
Date: Sun, 12 Jan 2014 21:21:27 + (UTC)
Author: hselasky
Date: Sun Jan 12 21:21:19 2014
New Revision: 260575
URL: http://svnweb.freebsd.org/changeset/base/260575
Log:
MFC r244607 and r244650:
Fix regression issues after r244503.
PR: usb/185628
Modified:
stable/9/sys/dev/usb/storage/ustorage_fs.c
stable/9/sys/dev/usb/usb_msctest.c
stable/9/sys/dev/usb/wlan/if_urtw.c
Directory Properties:
stable/9/sys/ (props changed)
stable/9/sys/dev/ (props changed)
Modified: stable/9/sys/dev/usb/storage/ustorage_fs.c
==
--- stable/9/sys/dev/usb/storage/ustorage_fs.c Sun Jan 12 21:19:49 2014
(r260574)
+++ stable/9/sys/dev/usb/storage/ustorage_fs.c Sun Jan 12 21:21:19 2014
(r260575)
@@ -603,6 +603,8 @@ tr_setup:
usbd_xfer_set_stall(xfer);
DPRINTF(stall pipe\n);
}
+ usbd_xfer_set_frame_len(xfer, 0,
+ sizeof(ustorage_fs_bbb_cbw_t));
usbd_transfer_submit(xfer);
break;
@@ -827,6 +829,8 @@ tr_setup:
sc-sc_transfer.data_error = 0;
usbd_xfer_set_stall(xfer);
}
+ usbd_xfer_set_frame_len(xfer, 0,
+ sizeof(ustorage_fs_bbb_csw_t));
usbd_transfer_submit(xfer);
break;
Modified: stable/9/sys/dev/usb/usb_msctest.c
==
--- stable/9/sys/dev/usb/usb_msctest.c Sun Jan 12 21:19:49 2014
(r260574)
+++ stable/9/sys/dev/usb/usb_msctest.c Sun Jan 12 21:21:19 2014
(r260575)
@@ -83,7 +83,7 @@ enum {
DIR_NONE,
};
-#define SCSI_MAX_LEN0x100
+#define SCSI_MAX_LENMAX(0x100, BULK_SIZE)
#define SCSI_INQ_LEN0x24
#define SCSI_SENSE_LEN 0xFF
@@ -150,6 +150,7 @@ struct bbb_transfer {
usb_size_t data_rem;/* bytes */
usb_timeout_t data_timeout; /* ms */
usb_frlength_t actlen; /* bytes */
+ usb_frlength_t buffer_size; /* bytes */
uint8_t cmd_len;/* bytes */
uint8_t dir;
@@ -192,7 +193,7 @@ static const struct usb_config bbb_confi
.type = UE_BULK,
.endpoint = UE_ADDR_ANY,
.direction = UE_DIR_IN,
- .bufsize = MAX(SCSI_MAX_LEN, BULK_SIZE),
+ .bufsize = SCSI_MAX_LEN,
.flags = {.proxy_buffer = 1,.short_xfer_ok = 1,},
.callback = bbb_data_read_callback,
.timeout = 4 * USB_MS_HZ, /* 4 seconds */
@@ -211,7 +212,7 @@ static const struct usb_config bbb_confi
.type = UE_BULK,
.endpoint = UE_ADDR_ANY,
.direction = UE_DIR_OUT,
- .bufsize = BULK_SIZE,
+ .bufsize = SCSI_MAX_LEN,
.flags = {.ext_buffer = 1,.proxy_buffer = 1,},
.callback = bbb_data_write_callback,
.timeout = 4 * USB_MS_HZ, /* 4 seconds */
@@ -299,6 +300,8 @@ bbb_command_callback(struct usb_xfer *xf
sc-cbw-bCDBLength = sizeof(sc-cbw-CBWCDB);
DPRINTFN(0, Truncating long command\n);
}
+ usbd_xfer_set_frame_len(xfer, 0,
+ sizeof(struct bbb_cbw));
usbd_transfer_submit(xfer);
break;
@@ -385,7 +388,7 @@ bbb_data_write_callback(struct usb_xfer
if (sc-data_rem == 0) {
bbb_transfer_start(sc, ST_STATUS);
- return;
+ break;
}
if (max_bulk sc-data_rem) {
max_bulk = sc-data_rem;
@@ -393,7 +396,7 @@ bbb_data_write_callback(struct usb_xfer
usbd_xfer_set_timeout(xfer, sc-data_timeout);
usbd_xfer_set_frame_data(xfer, 0, sc-data_ptr, max_bulk);
usbd_transfer_submit(xfer);
- return;
+ break;
default:/* Error */
if (error == USB_ERR_CANCELLED) {
@@ -401,8 +404,7 @@ bbb_data_write_callback(struct usb_xfer
} else {
bbb_transfer_start(sc, ST_DATA_WR_CS);
}
- return;
-
+ break;
}
}
@@ -437,6 +439,8 @@ bbb_status_callback(struct usb_xfer *xfe
break;
case USB_ST_SETUP:
+ usbd_xfer_set_frame_len(xfer, 0,
+ sizeof(struct bbb_csw));
usbd_transfer_submit(xfer);
Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
Hans, Our messages crossed -- a few minutes back I sent you this, which is how it is: From: Alex Goncharov alex_goncharov_...@yahoo.com Subject: Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321 To: Hans Petter Selasky h...@bitfrost.no Date: Sunday, January 12, 2014, 5:01 PM I just noticed your recent r260575 | hselasky | 2014-01-12 16:21:19 -0500 (Sun, 12 Jan 2014) | 5 lines MFC r244607 and r244650: Fix regression issues after r244503. PR: usb/185628 and am beginning a full rebuild; the results will be known in about three hours. Thank you! -- Alex On Sun, 1/12/14, Hans Petter Selasky h...@bitfrost.no wrote: Subject: Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321 To: Alex Goncharov alex_goncharov_...@yahoo.com, freebsd-usb@FreeBSD.org Date: Sunday, January 12, 2014, 4:30 PM On 01/12/14 18:20, Alex Goncharov wrote: The following reply was made to PR usb/185628; it has been noted by GNATS. Hi, Thank you for the logs. I see now what is going on. Your Seagate USB enclosures are crashing hard upon a zero length command block :-( And cannot recover afterwards. The others are not. It is related to some patches which I forgot to MFC to 9-stable which are already in 10 and 11, and not in 8-stable. Can you svn up to 9-stable and try again after this: http://svnweb.freebsd.org/changeset/base/260575 Thank you! --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
,-- From: Alex Goncharov alex_goncharov_...@yahoo.com Date: Sunday, January 12, 2014, 5:01 PM I just noticed your recent r260575 | hselasky | 2014-01-12 and am beginning a full rebuild; the results will be known in about three hours. Hans, While I am doing the rebuild, may I return to the topic I touched slightly in my original PR submission? A sporadic USB HDD device loss, sometimes with a system crash: I had this with a WD drive, when da0 could disappear at any moment, a file system vnode could not be found for reading or writing and bad things would happen. Now the same story with the Sony USB drive. My observations of many USB HDD's led me to conclude that some are smarter than the others -- the smarter ones may be slower to react to just about anything but they don't get lost. My Seagates may have a huge operation queues for either writing or reading, but I've never lost those drives' devices (da0s) when using them. 500G Buffalo never has a long queue, and good for it, but I am fine with a longer queue of the 1T Seagates, as long as their da0s don't go down. 1.5T Toshiba is another story: it seems like it often needs a significant wake-up period after sitting idle, but 'da0' never goes away, either. What WD and Sony exhibit on FreeBSD is plain horrible. It doesn't make sense to quickly write the first 10G of 100G of data if the system goes down after those 10G. And losing da0 on reading or after idling (the WD's behavior) is just as bad. As I mentioned, I didn't observe the Sony issue when using it on Linux (I didn't with WD -- just sent it back.) Can something be done about it along the Linux's lines, which you briefly mentioned and seemed to be critical about? As a data user, I strongly disagree that Linux's approach here is inferior to the one FreeBSD took, if I understand both correctly. Thank you, -- Alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
The PR problem is resolved after svn up with change r260575 in. Thank you, Hans! (I'd appreciate some action on my da0-out grievances. :) -- Alex On Sun, 1/12/14, Alex Goncharov alex_goncharov_...@yahoo.com wrote: Subject: Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321 To: freebsd-usb@FreeBSD.org, Hans Petter Selasky h...@bitfrost.no Date: Sunday, January 12, 2014, 5:28 PM ,-- From: Alex Goncharov alex_goncharov_...@yahoo.com Date: Sunday, January 12, 2014, 5:01 PM I just noticed your recent r260575 | hselasky | 2014-01-12 and am beginning a full rebuild; the results will be known in about three hours. Hans, While I am doing the rebuild, may I return to the topic I touched slightly in my original PR submission? A sporadic USB HDD device loss, sometimes with a system crash: I had this with a WD drive, when da0 could disappear at any moment, a file system vnode could not be found for reading or writing and bad things would happen. Now the same story with the Sony USB drive. My observations of many USB HDD's led me to conclude that some are smarter than the others -- the smarter ones may be slower to react to just about anything but they don't get lost. My Seagates may have a huge operation queues for either writing or reading, but I've never lost those drives' devices (da0s) when using them. 500G Buffalo never has a long queue, and good for it, but I am fine with a longer queue of the 1T Seagates, as long as their da0s don't go down. 1.5T Toshiba is another story: it seems like it often needs a significant wake-up period after sitting idle, but 'da0' never goes away, either. What WD and Sony exhibit on FreeBSD is plain horrible. It doesn't make sense to quickly write the first 10G of 100G of data if the system goes down after those 10G. And losing da0 on reading or after idling (the WD's behavior) is just as bad. As I mentioned, I didn't observe the Sony issue when using it on Linux (I didn't with WD -- just sent it back.) Can something be done about it along the Linux's lines, which you briefly mentioned and seemed to be critical about? As a data user, I strongly disagree that Linux's approach here is inferior to the one FreeBSD took, if I understand both correctly. Thank you, -- Alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
GPS ports in uhso
Hi I've been playing around getting GPS working with my GTM661W and the uhso driver. The ports are defined in uhso.c but in the method uhso_probe_iface_auto the GPS and GPSCTL ports are not in the switch(port) case. Is there a reason for this? I tried simply adding like this 823 case UHSO_PORT_TYPE_MODEM: 824 return (UHSO_IFACE_SPEC(UHSO_IF_BULK, 825 UHSO_PORT_SERIAL, port)); 826 case UHSO_PORT_TYPE_MSD: to 823 case UHSO_PORT_TYPE_GPS: 824 case UHSO_PORT_TYPE_GPSCTL: 825 case UHSO_PORT_TYPE_MODEM: 826 return (UHSO_IFACE_SPEC(UHSO_IF_BULK, 827 UHSO_PORT_SERIAL, port)); 828 case UHSO_PORT_TYPE_MSD: Sorry for the manual patch. I can send a patch file later if needed. I don't have an antenna at the moment so I can't confirm that the data is accurate but I'm getting output similar to what I expect in the GPS port and I can control it via the GPSCTL port. Best regards -- Johannes Lundberg -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: GPS ports in uhso
Hi Fredrik, Can you answer these questions: --HPS On 01/13/14 03:28, Lundberg, Johannes wrote: Hi I've been playing around getting GPS working with my GTM661W and the uhso driver. The ports are defined in uhso.c but in the method uhso_probe_iface_auto the GPS and GPSCTL ports are not in the switch(port) case. Is there a reason for this? I tried simply adding like this 823 case UHSO_PORT_TYPE_MODEM: 824 return (UHSO_IFACE_SPEC(UHSO_IF_BULK, 825 UHSO_PORT_SERIAL, port)); 826 case UHSO_PORT_TYPE_MSD: to 823 case UHSO_PORT_TYPE_GPS: 824 case UHSO_PORT_TYPE_GPSCTL: 825 case UHSO_PORT_TYPE_MODEM: 826 return (UHSO_IFACE_SPEC(UHSO_IF_BULK, 827 UHSO_PORT_SERIAL, port)); 828 case UHSO_PORT_TYPE_MSD: Sorry for the manual patch. I can send a patch file later if needed. I don't have an antenna at the moment so I can't confirm that the data is accurate but I'm getting output similar to what I expect in the GPS port and I can control it via the GPSCTL port. Best regards -- Johannes Lundberg ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
