8.0-RC1: AMD CS5536 (Geode) USB 2.0 controller strange behavour

[Eugene Grosbein]

> 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...

Eugene Grosbein