From owner-freebsd-hackers Tue Apr 4 19:20:51 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA29603 for hackers-outgoing; Tue, 4 Apr 1995 19:20:51 -0700 Received: from ast.com (irvine.ast.com [165.164.128.2]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id TAA29597 for ; Tue, 4 Apr 1995 19:20:46 -0700 Received: from trsvax.fw.ast.com (fw.ast.com) by ast.com with SMTP id AA14220 (5.67b/IDA-1.5 for freebsd-hackers@freefall.cdrom.com); Tue, 4 Apr 1995 19:23:56 -0700 Received: by trsvax.fw.ast.com (/\=-/\ Smail3.1.18.1 #18.1) id ; Tue, 4 Apr 95 21:17 CDT Received: by nemesis.lonestar.org (Smail3.1.27.1 #18) id m0rwKc9-0004vtC; Tue, 4 Apr 95 21:14 CDT Message-Id: Date: Tue, 4 Apr 95 21:14 CDT To: freebsd-hackers@freefall.cdrom.com From: uhclem@nemesis.lonestar.org (Frank Durda IV) Sent: Tue Apr 4 1995, 21:14:37 CDT Subject: Suggestion on slow probing devices Cc: uhclem@nemesis.lonestar.org Sender: hackers-owner@FreeBSD.org Precedence: bulk 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 |"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."