Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 4 Apr 1995 19:34:43 -0700 (PDT)
From:      "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
To:        steve2@freefall.cdrom.com (Steve Gerakines)
Cc:        freebsd-hackers@FreeBSD.org
Subject:   Re: Colorado Jumbo 250MB ft, and FreeBSD 2.0R
Message-ID:  <199504050234.TAA09378@gndrsh.aac.dev.com>
In-Reply-To: <199504050016.UAA05612@genesis.tiac.net> from "Steve Gerakines" at Apr 4, 95 08:16:43 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> 
> > The "ready for output in input" errors are par for the course.  Ignore them.
> > I thought I heard that the current maintainer of the driver was going to
> > get rid of them by 2.1, but they're still there.
> 
> I submitted a patch some time ago but nobody committed it.  There was also
> a fix in there to keep the motor from being activated during the probe for
> people who do not have tape drives.  I re-sent this fix to Rod a couple of
> weeks ago but I'm not sure what he's doing with it.

I have tested the patch here, and it is sitting in my tree ready for commit,
I am waiting on Joerg Wunsch to finish his review of it (since I only
had a drive to test with for a short time, and only one model of drive
I felt it best to get a second review before commiting).

> The fix within ft to avoid the messages works, but the correct way to
> remove them is to get them out of the fd driver in the first place.  In my
> opinion they should only be debug messages, since it's not as if the user
> can take some corrective action after seeing them.  It would be nice if
> someone did this before 2.1 is burned.

Some one from the fdc driver camp care to comment about this?

> Also, a number of people have reported to be having problems with the
> driver recognizing their tape drives.  They sound very much like
> timing problems.  At one time the timing characteristics of the driver
> worked for almost everyone as long as your CPU and bus speed was not
> on the extreme in either direction.  It seems with PCI and/or pentium
> systems this may no longer be the case.  Has anyone examined the DELAY
> (microtime?) function to see if it is running noticeably faster on those
> systems?

Bruce, do we need to something with the DELAY code?  I have 4 different
Pentiums here, 3 w/PCI if you need someone to run some test code.



-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation Company                   Custom computers for FreeBSD



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504050234.TAA09378>