Date: Mon, 6 Feb 1995 06:40:39 -0800 From: steve2@genesis.nred.ma.us (Steve Gerakines) To: freebsd-hackers@FreeBSD.org Subject: Re: FIX FOR CACHE/DMA RANGE PROBLEMS Message-ID: <199502061440.GAA20680@genesis.nred.ma.us>
next in thread | raw e-mail | index | archive | help
> > What exactly is the problem with the Ultrastor probe?? Please be specific. > > I wrote the 24F (EISA) probe virtually line by line from the spec. The > > only problem I know of which is now fixed, is that there was a faulty test > > to see if a 24F card was in wd emulation mode. > > The problem is that it doesn't first check the EISA device id registers > before doing inb/outb to the board. You should be able to 100% positive > id a board via the EISA id regs. Take a look in either aha1742.c or aic7770.c > to see how EISA boards should be found. The 24F probe does do this. It first checks slot | 0xc80 to see if an eisa card is there, and if it is we retrieve the id. If the id is not UHA024, it the card will be ignored. The problem with the ultra14f.c driver is that it first checks for a 14/34F, which will stomp registers. This should be no surprise though since all ISA/VLB drivers have to stop registers to some extent to find out if the card is there or not. > This is a different issue. I'm worried about the uha driver walking > over an already probed boards address area when there is no reason > why it should. At worst (the 24F probe anyhow) will retrieve the id of a board and find out it's not the one we're looking for. This should be non-destructive. > The different bus probe routines should be split out from the bus independant > portions of the driver. I agree that it would be nice to differentiate > between isa/eisa in config. The distinction is already made for PCI. This is basically what I'm saying. To take it one step further however, I don't think any eisa device should need to be hardcoded in config. There should be one routine (in i386/eisa/eisa.c perhaps? :-)) that scans the slots and retrieves board id's. If there was a table of EISA board id's and their associated probe()/attach() routines, eisa.c could look up the id and automatically config EISA devices. An EISA attach routine would be passed in the slot the board was found, and would be smart enough to retrieve and return the particular board settings. This way when a probe or attach routine is called it's known in advance that a card really does exist there. This takes the burden of scanning slots out of each driver and puts it in a central place. - Steve steve2@genesis.nred.ma.us
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502061440.GAA20680>