Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 4 Apr 95 21:14 CDT
From:      uhclem@nemesis.lonestar.org (Frank Durda IV)
To:        freebsd-hackers@freefall.cdrom.com
Cc:        uhclem@nemesis.lonestar.org
Subject:   Suggestion on slow probing devices
Message-ID:  <m0rwKc9-0004vtC@nemesis.lonestar.org>

next in thread | raw e-mail | index | archive | help
This is just a suggestion OK?  So no flaming about not being "BSDish"
enough right?  :-)

I wrote drivers on a XENIX system many years ago (it was better than doing 
PCDOS, OK?) and we had a terrible problem with devices that took forever to
initialize.  Some of the stupider devices took 30 to 45 seconds to even
show a hint of their presence, and we sometimes had to look for up to four
of these beasties at several addresses.  The time spent in what FreeBSD
calls probing and attaching reached up into the minutes range.  Marketing
was not happy with this and you know the rest of that story.

The solution was to create two probing passes.  The system would
effectively call each devices' probe routine twice.

The first time through the probe routine, it was to start anything that
took a long time, such as resetting devices, and/or doing media recalibrates
and then just return.  No messages were output in the first pass of any sort.
No result was returned on the presence or absence of hardware.  Then the next
device in config would get to be pre-probed.  (FYI, I believe we had
interrupts off all during this time.)

Once every driver had been "pre-probed", the kernel went off and did other
slow stuff, such as doing checksum on the code image, checking serial
numbers, testing the rest of RAM, initializing static drivers
(keyboard, DMA, interrupt controllers, etc), bufs, internal tables,
basically any slow stuff that we could put off until now.

Then the kernel would return and run probe a second time on all the devices.
Hopefully a lot of the resetting time for the various devices occurred
while the other devices were initializing AND IN PARALLEL so the delays at
this point were usually minor.

All we did was pass an extra parm to the probe routines indicating if it
was pass 1 or 2 and divided the tasks in each driver accordingly.  If a
driver figured out that it did or did not have hardware in pass 1, it
wouldn't say anything until it was re-run in pass 2.

We discovered that most block drivers could take advantage of this
and the code changes were quite minor.  The faster boot-up speed
was a big plus and there was no combination of drivers that resulted in
a longer boot time. 
This technique cut the boot time to 1/4th of what it was.


For FreeBSD something similar could be implemented, although I suggest
adding an entry in kenrel config indicating if a given driver is capable
of being probed twice so that we don't have to modify all the drivers
at once.   If the driver isn't a two-pass driver, it would be probed
only during the second pass, which would be equivalent to the pass
that is done now.

So as we update a given driver, that driver's wait-time would be
shared with the overhead of some other driver or basic system
initialization rather than each driver sitting in a timing loop, one
at a time, wait for its devices to go ready before letting the
next driver run and reset and wait on its devices.

FreeBSD already has several drivers that have to wait a long time
when initializing that could take advantage of such a scheme.  SCSI
and the proprietary CD-ROM drivers come to mind.

Granted there are some drivers that issue a command to a port, wait
(or settle) a few seconds and decide the hardware isn't there, issue a
command to a different port, wait again, timeout and move along, etc.
The above scheme would put the first of those waits in parallel with other
options but the additional delays would still be done serially.  But you
still saved time.


Comments?

Frank Durda IV <uhclem@nemesis.lonestar.org>|"Hey Moe!  This pipe is all
or  uhclem%nemesis@trsvax.ast.com (Internet)| full of wires!"
...letni!rwsys!nemesis!uhclem               |"Well, rip 'em out!"
...decvax!trsvax.fw.ast.com!nemesis!uhclem  | Notes from a typical management
					      network planning session."





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