Date: Sun, 10 Jul 2005 15:14:03 +0200 From: Stefan Walter <sw@gegenunendlich.de> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: usb/82660: EHCI: I/O stuck in state 'physrd'/panic Message-ID: <20050710131403.GA1743@kyuzo.dunkelkammer.void> In-Reply-To: <200507101301.04434.hselasky@c2i.net> References: <20050626091628.775DD3A1D@kyuzo.dunkelkammer.void> <200507092352.33451.hselasky@c2i.net> <20050710093359.GA840@kyuzo.dunkelkammer.void> <200507101301.04434.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--qMm9M+Fa2AknHoGS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hans Petter Selasky, 10.07.05, 13:01h CEST:
> Again, I cannot see any errors. The 13 bytes this transfer should transfe=
r are=20
> the 13 bytes of the CSW. Is it possible that you could connect two USB 2.=
0=20
> flash disks to the same USB controller and see if they both hang at the s=
ame=20
> time. That might indicate that there is something wrong with the EHCI dri=
ver.
They don't. When a transfer from one device is currently hanging, I can
still transfer data from another device (until, eventually, that one hangs
as well). The two transfers don't resume at the same point of time,
either.
> I had another look at /sys/dev/usb/umass.c and wondered why the CSW has t=
he=20
> same timeout as the data transfer.
>=20
> Add:
> sc->timeout =3D 1000;
> Before:
>=20
> /* Read the Command Status Wrapper via bulk-in endpoint. =
*/
> if (umass_setup_transfer(sc, sc->bulkin_pipe,
> &sc->csw, UMASS_BBB_CSW_SIZE, 0,
> next_xfer)) {
> umass_bbb_reset(sc, STATUS_WIRE_FAILED);
> return;
> }
>=20
> This will shorten the time the driver will wait before doing the reset, a=
nd=20
> your device might work better.
Thanks. I haven't tried that, yet, but I will.
> Could you have verified the checksum of the files you are reading/writing=
=20
> while this error happens, and see that no data is lost?
I hadn't seen any corruption with the files transferred, and a quick check
with the external HD enclosure (it also supports FireWire, which works
fine) showed correct MD5 checksums.
Stefan
--qMm9M+Fa2AknHoGS
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (FreeBSD)
iQGVAwUBQtEfG1aRERsSueCzAQIDNgv/dGUj9Lf2zHVr9rwv+kOBpCns9Bn7Nq71
ERlS9XNmsvMEsEQL8FI/1/VzvmeWjk5TzIC0+G568SXuL37Yc7F06M70VNouoxt7
v032JKFqDb0Gju+xqzmFlSKxjk4q0qZcp099qrfoau7RngYKn6nNyGm6+LgLiR8E
1fMJXVAD0LWR5QGi3OpQDAA6EjmvU3cHXGYnk/Rj+/wCTAkIkRvZB50vM6It708z
uUclCaGckkPpwSON9Q0t8oYQNHXZdsBKiU6h+bVuC04JD/jttnPcpPm44s6LWCjR
2F+kLKFwxW3DoL6rFB8/fl+Us4VlAoVUuwPQTQnSRPAWf5Ije65fCaG/LElIkNyN
Eand6gPB5KRK/cqfSNil5Tz+G9SBJQa1GUsc6tST6YOLkyfS1DZwV483otiMoCAL
nGrJQOmmTcTJoS5tGfapmFYErdmOk0Wi6jSkllNnU1brzjZMyQFN1U/cHQiRtfCN
gXtE2ghcebJztLkcq1BbDBl4c/HZ9gQE
=x+6z
-----END PGP SIGNATURE-----
--qMm9M+Fa2AknHoGS--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050710131403.GA1743>