Date: Fri, 1 Dec 1995 17:30:33 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: awebster@dataradio.com (Andrew Webster) Cc: freebsd-questions@freebsd.org Subject: Re: Strange Multi-port SIO behaviour Message-ID: <199512020030.RAA02886@phaeton.artisoft.com> In-Reply-To: <199511291539.KAA05360@vhf.dataradio.com> from "Andrew Webster" at Nov 29, 95 10:40:27 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I've noticed on systems with AST/4 port and Digi PC/4/8 cards that > when a soft-reboot occurs (i.e. after crash/panic), the SIO ports are > not all initialized properly, whereas after a shutdown -r or reboot, > or cold boot the ports all init properly. > > I've looked at the sioprobe function in the sio.c module and there > appears to be lots of instances where the programmer added > EXTRA_DELAY? Has anyone else seen this problem? > > Appart from forcing the machine to reboot if all the sio ports are > not detected, is there a clean way to make sioprobe find all the > ports after a crash? The problem is in the probe. Because the ISA bus does not have per slot device identification mechanisms like EISA (which doesn't have a set per slot memory size), MAC (which does), and PCI, an ISA device must be "probed". A probe can be destructive (it pokes the devices to see if it says "ouch") or non-destructive (it looks for a ROM or a memory range checksum, or some other characteristic that the device does not share with any other device). The problem with non-destructive probes is that they rely on the device being in a known state so that the checksum will match, etc., and the device will be found. The AST/4 and Digi PC/4/8 cards device driver relies on the device being in a known state. So do a number of the ethernet drivers. That state is the state that the card is in after POST (Power On Self Test). In the event of a crash, the system will typically be frozen. So that's not a recoverable case without a human to hit a reset switch anyway. Or the power went off then on, and it acts as if a human caused a cold start. In the event of a panic, you have a problem. The card driver "attach" routine, once the card is probed and found to exist, must change the state information that the probe depends on to actually use the card. This could be considered a problem with the card POST leaving the card in a less than useful state. This is typically not a real problem, however. When the system is rebooted under software control, it's done by one of several methods. Only EISA nad PCI systems support full system reset controls. It's an error that on EISA and PCI systems, FreeBSD doesn't use these techniques to reboot the system. Another method of doing a reboot is to cause the keyboard controller to strobe the reset line. This may or may not work, since some keyboard BIOS rely on the Gate A20 setting and default page mapping to allow the keyboard reset technique to work. When it does work, the reset strobe can be implemented a couple of different ways (described below). If the keyboard reset fails, then an attempt is made to cause the processor to triple fault. A triple fault will cause a soft reset strobe to occur. A triple fault is the type of "crash" that will cause the machine to reboot if it isn't caught by a panic. In general, there aren't any known bugs that will result in spurious triple faults. Now the reset strobe can cause one of two actions: (1) a soft reset (2) a hard reset If a hard reset occurs, the bus will be reset and the cards will rerun their post code and you won't have a problem. If a soft reset occurs, though, the post code will not be run unless the soft reset forces a bus reset. This is what leaves the card in an indeterminate state and causes the probe to fail when the system is reloaded. You might notice that internal serial ports with FIFO's enabled are not reset correctly even on a hard reset. This is the result of a stupid BIOS that doesn't know about the hardware in the machine and doesn't reset the FIFO's to "disabled". In any case, if the probe executes after an attach without an intervening hard reset it can fail. So it fails because of one of: 1) Bad POST code: doesn't really return decive to the power on state after hard reset (BIOS BUG or Card design BUG). 2) Bad keyboard BIOS (or bad FreeBSD implementation of reset) causes keyoard based reset to fail (BIOS or FreeBSD BUG). 3) Soft reset from keyboard reset instead of hard reset causes POST to be skipped (Motherboard design BUG). So there are several obvious ways to fix the problem, but none of them can happen overnight. The most obvious of these is discard all ISA based hardware or buy only ASUS or other high quality motherboards. The others, in order, are: rewrite the probe code to be destructive (may screw up other cards in probe), rewrite the probe code to work even after attach (may not be possible), use other cards. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512020030.RAA02886>