Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!metro!ipso!runxtsa!bde From: bde@runx.oz.au (Bruce Evans) Subject: Re: my bug list Message-ID: <1993Mar31.085440.23391@runx.oz.au> Organization: RUNX Un*x Timeshare. Sydney, Australia. References: <DERAADT.93Mar25202827@newt.fsa.ca> <1993Mar30.020058.3999@fcom.cc.utah.edu> <CGD.93Mar30023216@erewhon.CS.Berkeley.EDU> Date: Wed, 31 Mar 93 08:54:40 GMT Lines: 53 In article <CGD.93Mar30023216@erewhon.CS.Berkeley.EDU> cgd@erewhon.CS.Berkeley.EDU (Chris G. Demetriou) writes: >In article <1993Mar30.020058.3999@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: > >for example, bruce evans' serial driver forces and interrupt, >though i forget whether or not it checks to see which one it is... >in any case, that should be easy enough. It checks, and writes off the port if the specified interrupt doesn't happen. Interrupt numbers are currently cemented into the code for each hander (more so in my rewrite of interrupt handling). This gives some small speed advantages but makes it harder to support probe-time determined interrupt numbers. >you look at the addresses that the device is sitting at, >see if it looks right, then make it interrupt. if it does >the right thing, THEN AND ONLY THEN do you say that it's the >device, and, while you're at it, you get it's real IRQ number >for free. >... >[how to probe for devices in the order specified in the config file] I see several problems. (1) Frying some hardware while probing for other h/w. This isn't much of a problem in practice, but I'd prefer not to sign for a big and complicated GENERICISA file that will be tried on lots of systems. (2) Linear ordering of the probes may not be sufficient and/or it may be difficult to write big GENERICISA files with suitable ordering. (When a device can be mapped at several addresses, better pick an address that doesn't restrict other probes). (3) Linear ordering of probes is _not_ sufficient for handling overlapped programmable address ranges. E.g., suppose devices 1 and 2 can be programmed to use either of the address ranges A1 and A2, and both devices can work at once, and you have just rebooted from another system that programmed range A2 for device 1 and A1 for device 2. Better not probe A1 for device 1 while A1 for device 2 is active. It doesn't help to reset device 1. (4) Linear ordering of probes is _not_ sufficient for handling standard dumb com devices that share an interrupt. It is necessary to enable exactky one of the interrupt gates. Enabling more than one may burn out something, and enabling none may cause the interrupt line to float (on my system it floats high and causes a com interrupt when all com interrupts are disabled!). At least one round of partial probes is is required to disable the interrupts before full probes can be done. You lose if the config doesn't mention an active device. -- Bruce Evans bde@runx.oz.au