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

Reply via email to