On Tue Oct 19 10, Matthew Jacob wrote:
> It would be an effective behavioral change for those of us who remove
> that line.
> Personally, I think 5 seconds is too long- even 2 seconds is more than
> adequate even for moderately old 'other' hardware like scanners.
>
> For -current, why don't you simply remove all of the config lines and
> leave the default at 2000ms?
hmmm...i can only test the delay value on amd64. i was under the impression
that archs like arm and mips need the longer delay.
also at some locations in the code SCSI_DELAY is being set to 15000. i believe
this is the case when certain drivers (cam, ahb, aha) get loaded as a kernel
module, but i'm not sure. it looks like this:
.if !defined(KERNBUILDDIR)
opt_scsi.h:
echo "#define SCSI_DELAY 15000" > ${.TARGET}
.endif
cheers.
alex
>
> On 10/19/2010 3:34 AM, Alexander Best wrote:
> >On Mon Oct 18 10, Matthew Jacob wrote:
> >> What problem are you solving by this change?
> >code cleanup.
> >
> >the scsi delay value currently defaults to 2000ms. however that doesn't
> >make
> >sense, since on almost all platforms it gets set to 5000ms in the default
> >config. what's the purpose of having a default value, if it is much more
> >often
> >overwritten than actually used?
> >
> >that's why this patch changes the default scsi delay value to 5000ms. now
> >all
> >of the lines that were setting the scsi delay value to 5000ms can be
> >removed.
> >also default values should be chosen very conservatively. users can always
> >lower the delay value via their kernel config or sysctl.
> >
> >cheers.
> >alex
>
--
a13x
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
