Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!umd5!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.unix.wizards Subject: Re: Autoconfig Message-ID: <12255@mimsy.UUCP> Date: 30 Jun 88 20:51:29 GMT References: <9600@eddie.MIT.EDU> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 39 In article <9600@eddie.MIT.EDU> nessus@athena.mit.edu (Doug Alan) writes: >I'm led to believe from reading "Building Berkeley UNIX* Kernels with >Config", that if your system works, you should be able to power down >your system, pull out a controller from the bus (replacing it with a >grant card), and reboot the system, and your system will still boot, >as long as the controller that you removed wasn't critical for booting. More or less. >... For some boards it works. ... For some controllers, the system hangs >when it gets to the point in the autoconfig sequence where the missing >controller would normally be found. This is probably a driver bug: one that does something like ((struct foodevice *)reg)->csr = FOO_INIT; while ((((struct foodevice *)reg)->csr & FOO_DONE) == 0) /* spin */; or something equally wrong. >A more peculiar mode of failure happens when I remove a second dis >controller. The autoconfig sequence finds the first controller twice! >And both times it finds it at the same CSR address. A small bug, fixed in 4.3BSD-tahoe. (The test for ualloc[addr] is missing.) >... We [also] have a uVax-II with two [Sigma] controllers and the >aforementioned kernal. It also has a Wespecorp tape controller. >I want to put in a DHV11, but whenever I do, it doesn't work right. >With the DHV11 in, autoconfig seems to find it fine, but if I try >to [use it] it hangs. ... Another problem that seems to occur with >the DHV11 in, is that some C programs, occasionally, when trying to >dump core, cause the whole system to become wedged. Sounds like either a hardware problem or a bug in one of the drivers that hogs Unibus (Qbus) map resources. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris