From owner-freebsd-usb@FreeBSD.ORG Sun Sep 27 14:43:52 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34D8D1065692 for ; Sun, 27 Sep 2009 14:43:52 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe12.swipnet.se [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 9051A8FC2F for ; Sun, 27 Sep 2009 14:43:51 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=pZqXNPWrx7QA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=RJzJ1XmNAAAA:8 a=E9OOGue6BBqRPtDuEKgA:9 a=nXSt2WG46QiWXVAgvlwA:7 a=0bPjovdrJUCA5ljWh_vxouZhDJ8A:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe12.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1136536560; Sun, 27 Sep 2009 16:28:50 +0200 Received-SPF: softfail receiver=mailfe12.swip.net; client-ip=188.126.201.140; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Sun, 27 Sep 2009 16:29:29 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20090927141205.GA19251@svzserv.kemerovo.su> In-Reply-To: <20090927141205.GA19251@svzserv.kemerovo.su> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909271629.31368.hselasky@freebsd.org> Cc: Eugene Grosbein Subject: Re: 8.0-RC1: AMD CS5536 (Geode) USB 2.0 controller strange behavour X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 14:43:52 -0000 On Sunday 27 September 2009 16:12:05 Eugene Grosbein wrote: > > Could you check if these are due to device timeouts in the CAM layer? > > There is some debugging you can turn on: > > > > sysctl hw.usb.umass.debug=-1 > > > > Probably it will flood the console. > > That's not a problem. Anyway, I rlogin to this system > and use syslog to write all console/kernel logs to console.log > and kernel.log > > So, I have done: > > %sysctl hw.usb.umass.debug=-1 > hw.usb.umass.debug: 0 -> -1 > > Then used another terminal to ran: > > %iostat -d -K -w 10 da0 > da0 > KB/t tps MB/s > 2.88 0 0.00 > > After it started, I switched back to first terminal and ran: > > %dd if=/dev/zero bs=64k of=/dev/da0 count=1000 > > It started to work, meantime iostat output was: > > 63.62 17 1.05 > 0.00 0 0.00 > 0.00 0 0.00 > 0.00 0 0.00 > 0.00 0 0.00 > 0.00 0 0.00 > 64.00 2 0.15 > 62.31 83 5.06 > 0.25 0 0.00 > 0.00 0 0.00 > 0.00 0 0.00 > ^C > > To this moment, dd has finished his work and printed: > > 1000+0 records in > 1000+0 records out > 65536000 bytes transferred in 78.627073 secs (833504 bytes/sec) > > One can see, it sent first chunk of data to the device > than there was quite large period of time without any activity, > more than 50 seconds. Then it has finished. > > As for debug log, its uncompressed size is over megabyte > so I've made it available here (25KB compressed): > > http://www.grosbein.pp.ru/umass.log.gz > > I cannot read/understand it yet. > > > Maybe you could add some prints to > > /sys/dev/usb/storage/umass.c in all the "default:" cases in the USB > > callbacks and print out the "error" code. That would quickly indicate if > > your device has an issue with timing, I.E. that the firmware in the USB > > device part is hanging. > > I still suppose the device is fine because it presents no such problem > being connected to another box with the same 8.0-RC1 (same sources). > > Also, I don't feel myself confident with the code to debug it yet... > Hi, The following debug prints clearly show that your device does not respond. And the USB stack kicks in after a while to fetch the status of the drive. Previously when I have seen this kind of issues, it was always the USB device stack that was at failure. I've never seen that it was the fault of the USB host stack. You would need an USB analyser to figure out for sure. If the situation is that the USB device hardware is reponding with NAKs to the OUT or PING tokens (USB term), then the schedule on the USB host is setup correctly and it is a device problem. Have you tried contacting the manufacturer of your USB device about this? What is the CPU speed difference between the two boxes you are running tests on? Sep 27 21:50:13 gw kernel: umass0:umass_dump_buffer: 0x 00000000000000000000000000000000 ... Sep 27 21:50:13 gw kernel: umass0:umass_bbb_dump_cbw: CBW 208: cmd = 10b (0x2a0000005400...), data = 65536b, lun = 0, dir = out Sep 27 21:50:13 gw kernel: umass0:umass_transfer_start: transfer index = 6 Sep 27 21:50:13 gw kernel: umass0:umass_t_bbb_data_write_callback: max_bulk=131072, data_rem=65536 Sep 27 21:51:17 gw kernel: umass0:umass_transfer_start: transfer index = 7 Sep 27 21:51:17 gw kernel: umass0:umass_transfer_start: transfer index = 8 Sep 27 21:51:17 gw kernel: umass0:umass_bbb_dump_csw: CSW 208: sig = 0x53425355 (valid), tag = 0x000000d0, res = 65536, status = 0x01 (failed) Sep 27 21:51:17 gw kernel: umass0:umass_t_bbb_status_callback: Command failed, residue = 65536 --HPS