Date: Wed, 5 Apr 95 20:11 CDT From: uhclem@nemesis.lonestar.org (Frank Durda IV) To: peter@bonkers.taronga.com, freebsd-hackers@freefall.cdrom.com, phk@login.dknet.dk Cc: uhclem@nemesis.lonestar.org Subject: Re: Suggestion on slow probing devices Message-ID: <m0rwg6G-0004vtC@nemesis.lonestar.org>
next in thread | raw e-mail | index | archive | help
[0]The solution was to create two probing passes. The system would [0]effectively call each devices' probe routine twice. [1]Peter writes (who actually used to use a system based on the above [1] scheme and probably didn't even know it) :-) [1]How about generalizing it? If there's a big delay, have the probe [1]return a flag saying "more work to do, call me again after you've [1]asked everyone else". That way you could handle multi-stage delays, [1]like with SCSI. If you say, "OK, I'll start one slow thing, then bail out and let everyone else initialize" (including the others who also quickly bail out), then after a bit the ball comes back to you. Now what? If you start something else slow and then say "come back later", there will be less and less other drivers needing initialization to spend the intervening time on. Eventually your slowest one or two devices will just be executing themselves or each other over and over again. Result: you added a lot of complexity by implementing drivers that can be probed "n" times but gained little or zero in performance. We did something like what you suggest in the original implementation and found that the the code got more complex and the speed increase was so low we had a hard time measuring it as anything other than disk latency. We went back to two passes. Note that if you have two devices that both took a long time, but the number of slow things each had to do was different and each slow thing took a different amount of time, you would see a gain. But designing for such a special case wasn't worthwhile. The other reason I proposed doing the bulk of the work in the second of two passes (which would be the only pass that unmodified drivers would run) would be to ensure that the bulk of the probing/attaching code ran and the resulting probe/attach reports ended up getting displayed in the same order that the entries appear in the config file. Now you might say, "who cares?", but knowing what the next driver is after the last one that displayed a message before your system locked-up is somewhat useful. Doing multiple passes also causes some bizzare device report ordering unless you made things real complex inside. Lets say you have two IDE drives (slow) and a couple SIO ports (not slow) and a SCSI adapter (incredibly slow) with a couple of controllers (drives). Your bootup log might look like: (Example of n passes, NOT what I am suggesting) Pass message The normal log message output in P1 Probing for devices on the ISA bus: P1 wdc0 at 0x1f0-0x1f7 irq 14 on isa (Start reset and move on) P1 aha0: reading board settings, dma=5 int=11 (bus speed defaulted) P1 aha0 at 0x330-0x333 irq 11 drq 5 on isa P1 aha0 waiting for scsi devices to settle (Start wait on controller 0 and move on) P1 sio0 at 0x3f8-0x3ff irq 4 on isa P1 sio0: type 16550A (Fast device so it is all done) P1 sio1 at 0x2f8-0x2ff irq 3 on isa P1 sio1: type 16550A (Fast device so it is all done) P1 sio2 not found at 0x3e8 (Fast device so it is all done) P1 sio3 not found at 0x2e8 (Fast device so it is all done) (Ok, all devices examined once, now back to the top) P2 wdc0: unit 0 (wd0): <WDC AC2540H> P2 wd0: 515MB (1056384 total sec), 1048 cyl, 16 head, 63 sec, bytes/sec 512 (Start wait on IDE slave and move on) (sio is all done so they don't get run) P2 aha0 targ 0 lun 0: type 0(direct) fixed SCSI2 P2 aha0 targ 0 lun 0: <SEAGATE ST12550N 0013> P2 sd0: 2040MB (4178874 total sec), 2708 cyl, 19 head, P2 81 sec, bytes/sec 512 (Start wait on SCSI controller 1 and move on) (Ok, back to the top again (wdc and aha are still left)) P3 wd1: not found (sio is all done so they don't get run) (No SCSI controller 1 present) (Start wait on SCSI controller 2 and move on) (Ok, back to the top again (aha is still left)) (wd is all done so it doesn't get run) (sio is all done so they don't get run) P4 aha0 targ 2 lun 0: type 1(sequential) removable SCSI1 P4 aha0 targ 2 lun 0: <ARCHIVE VIPER 150 21247-005> P4 st0: Archive Viper 150 is a known rogue P4 st0: density code 0x0, drive empty (Start wait on SCSI controller 3 and move on) (Ok, back to the top again (aha is still left)) P5 thru n No messages but we take a few more passes looking for more SCSI controllers or possibly a second IDE interface. Or worse, a second aha host adapter card using the same driver, causing up to 6 additional passes. If you just look at the log, the resulting order of messages will make it difficult if not impossible for the average sysadmin to figure out what ran after what. But, if you start resets (settles) and other slow stuff in a silent pass 1 and then probe normally or run the rest of the probe in a second pass, the messages come out as before, the bulk of driver code with any "hang potential" gets run in a nice known order and if you are trying to get things located in a certain way in memory, you can still do it simply by config placement. That will become useful when PnP gets to FreeBSD. Sorry I didn't explain why things were they way they were more clearly. [2]Poul-Henning Kamp <phk@login.dknet.dk> [2]I'd say the right thing to do would be to get the timer flying and make [2]a "HW-probe-attach" process... Well, this is great if you don't mind having a process that must finish before you can let swap or init run. (Process -1?) Unless you have knowledge about what the boot device is and can probe and attach it first you really can't let anything get going. Also consider your video drivers aren't running yet when this process starts, plus a few other odds and ends like a filesystem you will need to access unless you embed the process image somewhere in the kernel binary (ugh). Sounds messy. Were you thinking of having the process issue PROBE and ATTACH ioctls or some similar mechanism until the drivers said they were done? Of course this blue-sky is all ruined if we get really wound up and decide to support PnP devices. PnP initialization is slow anyway because of the way it is implemented. If the "core patrol" wants me to take a look at experimentally hacking some of the CD-ROM drivers and the isa front end to do a two-pass init, and see what is involved, I'll look into it. I'll pass on offering to touch the SCSI code for now. I'm not nearly insane enough. :-) Frank Durda IV <uhclem@nemesis.lonestar.org>|"I'll huff, and I'll puff, or uhclem%nemesis@trsvax.ast.com (Internet)| and I'll get promoted." ...letni!rwsys!nemesis!uhclem | - Old management saying ...decvax!trsvax.fw.ast.com!nemesis!uhclem |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0rwg6G-0004vtC>