Date: Sun, 3 Jul 2005 09:56:32 +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: <20050703075632.GA937@kyuzo.dunkelkammer.void> In-Reply-To: <200507021553.49043.hselasky@c2i.net> References: <20050626091628.775DD3A1D@kyuzo.dunkelkammer.void> <200507011210.25250.hselasky@c2i.net> <20050701114207.GA826@kyuzo.dunkelkammer.void> <200507021553.49043.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hans Petter Selasky, 02.07.05, 15:53h CEST: > > http://www.gegenunendlich.de/stuff/messages-umass-until-pullout.bz2 > > http://www.gegenunendlich.de/stuff/messages-umass-after-pullout.diff >=20 > The end of the log is just before you pulled out your device, when the er= ror=20 > happened, right? Yes, but... > I'm not sure what is wrong. From what I can see the problem is in an uppe= r=20 > layer, hence UMASS's USB transfers should timeout at least, if they get= =20 > stuck. =2E..maybe I pulled the stick out too quickly until now. I just noticed that, when I'm patient enough, the transfer is eventually resumed (after about two minutes). Some data is transferred (size varying), then it stalls again. I didn't notice that before. I've uploaded a message log of a complete transfer of a 17 MB file (that is, the file was successfully copied to the hard disk with mtools) now (with hw.usb.umass.debug=3D-1): http://www.gegenunendlich.de/stuff/ehci/umass-messages-complete-transfer.bz2 The log also contains messages of sudo(8) being called. I ran sudo every time I noticed that some data had been copied and the transfer stalled again to mark those points of time in the log. You'll notice umass timeout messages around those ones. I hope this one is a bit more helpful than the others. > While having [umass] debugging enabled, could you have tried playing=20 > around with "camcontrol" and see if it changes anything: >=20 > man camcontrol > camcontrol devlist > camcontrol reset scbus0:0:0=20 >=20 > # replace "0:0" with "target" and "lun" for the device you are reading fr= om I did reset the device with another stalled transfer a few times. It didn't resume the transfer, but here's a log: http://www.gegenunendlich.de/stuff/ehci/umass-messages-bus-reset.bz2 > Could you have tried another brand of USB 2.0 flash disks and see if the= =20 > problem is the same? Currently not, no. I thought the other device I have was USB 2.0, too, but I was wrong. Stefan --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iQGVAwUBQseaMFaRERsSueCzAQI68AwAuX/lZ/Op49eDvlfZicKFiDQc1oWfV1Ga XEhyT55qCHp94B6OQHSEOioElsXoKKoXDd3iAklSilJO9lyeUG2Tb+V1MLse4IdD Px2edp97tPUXU7GvA6yT0ApQ7rNp93E4QXNyY8IOnsVPMGSlmPGPD+jGv1CQBmCm iIn16nXeNN/yjQfzrUNbBMLFv4qaEEzKaegYDJ3/AXYdgYT4hJlX3k6KYFj4UL8d z1hcaJwgqVWnEtFFHLO7icX8jFMnIYo5TVnEKc9BtSfwjjpEpngmSdBDAdDAOrXl mS2CZG3l03uf7K2vmzZx7+sHS4uT7lhFpTzNrARqmzrXDzW8R2AxHb1zkMafV44J 0uYQxtvM81dPxt2/MdgTBIcaEDL7tgNfXepEhOy2nd9NUmOmsCBD6AJdLO8+aujt m1YujdqapkMmMR+g/EWIF6+4Qr1uD9cJfCPKdYm+/5GhB12DhdnnZfhyK6pQDfPf esyQlBcQ+FcdzCyH76Ddi7iO1UafppO9 =IvOx -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050703075632.GA937>