At Thu, 6 Feb 2003 12:15:38 +0100 (CET), Michael Reifenberger wrote: > > On Wed, 5 Feb 2003, Michael Reifenberger wrote: > ... > > > I have improved recovery code after timeout in -current. > > > Could you try that? > > > > Is scheduled for this evening. > > Thanks so far! > > > ... > > > > > - fwcontorl -g 20 > > > > > - sysctl hw.firewire.sbp.max_speed=0 > > > > > - change SBP_QUEUE_LEN in sbp.c to 1 and rebuld module. > > > > > - sysctl machdep.cpu_idle_hlt=0 > > > > > - sysctl debug.sbp_debug=1 and send me a dmesg. > > Ok, I did some extensive tests overnight. > Essentially I still had `fwcontorl -g 20` and > SBP_QUEUE_LEN=1 and maxopenings=1 and `debug.sbp_debug=1`. > hw.firewire.sbp.max_speed started at 0 and got 2 at the end. > After treating two `iozone -s 51200m -r1024k` on the platters > overnight without problems I started with a plain sbp.c and > no `fwcontorl -g 20`. I get constant rates of 13MB/s on each disk. > No problems so far. > Seems you got it. Thanks!
Do you have any timeout while the test? I think SBP_QUEUE_LEN or maxopenings is the important parameter. Can you try to change thoes values? > BTW: switching on debug.firewire_debug gives zillions of 'kick'... > Is this just a notification about the code-path? Yes, but it doesn't seem necessary anymore, removed. Thanks, /\ Hidetoshi Shimokawa \/ [EMAIL PROTECTED] PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message