Date: Sun, 27 Sep 2009 16:29:29 +0200 From: Hans Petter Selasky <hselasky@freebsd.org> To: freebsd-usb@freebsd.org Cc: Eugene Grosbein <eugen@kuzbass.ru> Subject: Re: 8.0-RC1: AMD CS5536 (Geode) USB 2.0 controller strange behavour Message-ID: <200909271629.31368.hselasky@freebsd.org> In-Reply-To: <20090927141205.GA19251@svzserv.kemerovo.su> References: <20090927141205.GA19251@svzserv.kemerovo.su>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200909271629.31368.hselasky>