Date: Sun, 12 Jan 97 12:19:21 +0900 From: tedm@agora.rdrop.com To: freebsd-bugs@freebsd.org Cc: joerg_wunsch@uriah.heep.sax.de, gibbs@freefall.freebsd.org Subject: Re: conf/2367: Buslogic SCSI driver bad probe of 742A early revision IRQ and version Message-ID: <9701122034.AA0057@agora.rdrop.com>
next in thread | raw e-mail | index | archive | help
Just an update on this: I have compared 4 different revisions of EISA-config files for the 742A, and unfortunately they all use the same codes and port locations for the configuration data. Buslogic apparently didn't change any of this with the different 742A revisions. Looking through the /eisa/bt74x.c code, I cannot see anything obviously wrong with it, the ports that the probe is querying match what is listed in all of the eisa-config files, as well as the codes that it is extracting. I also discovered two other things, first that the probe also fails on the port number as well as the IRQ, it always returns port 330 regardless of the eisa-config setting of the port. Second, I hard-coded a different IRQ number into the code, recompiled and rebooted and re-configed the card to match that IP number, and it still fails even though the probe returns with my set IRQ number. The one guess that I have is that the 330 and IRQ9 probe selections are picked when the return code is zero. Perhaps there is an error in the bt74x.c code where the switch selection is being made on a variable instead of a pointer, or some such? Unfortunately my C skills are not good enough to be able to just look at the probe code and immediately know what is going on, also the probe code is scattered between eisaconf.c and the various device driver probe files, which makes it kind of difficult to follow. Any suggestions on where to concentrate? I feel sure that the problem is in bt74x.c somewhere. //---------------------------------------------------------------------------- // Ted Mittelstaedt See my "Network Community" columns online // tedm@agora.rdrop.com at http://www.computerbits.com // tedm%toybox@agora.rdrop.com //--- forwarded letter ------------------------------------------------------- > MIME-Version: 1.0 > Date: Sun, 05 Jan 97 15:55:25 -0800 > From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org> > To: joerg_wunsch@uriah.heep.sax.de > Cc: tedm%toybox@agora.rdrop.com, > freebsd-bugs@freebsd.org > Subject: Re: conf/2367: Buslogic SCSI driver bad probe of 742A early revision IRQ and version > > >As tedm@agora.rdrop.com wrote: > > > >> > Ok. So the basic problem of your PR is solved then? > > > >> Absolutely not. Either the driver or the EISA probe is messed up, > >> despite disabling the ISA buslogic driver using boot -c, the probe > >> still responds with IRQ=9, regardless of the actual setting of the > >> hardware in EISA-config. > > > >Well, unless you can dig into details, this is unlikely to ever be > >resolved. There are only very few developers around that still use > >EISA boards, and all the boards i had or have access to (the old SiS > >chipset one, and an ASUS PCI/EISA twin-CPU one) didn't fail FreeBSD's > >EISA probe. That's why i'm suspecting your hardware. > > I would guess that he has a revision of the Buslogic card that simply > doesn't map to the EISA configuration file I used to write the EISA > Buslogic probe. This should be easy to fix so long as the revision > information in the EISA config information can be used to differentiate > boards with different configuration layouts. If you take your EISA config > file and take a look at the probe code for the 74X cards, you should be > able to fix this very quickly. > > As for not honoring the setings reported later in the probe this arises > from looking at two different sources for configuration information. > The EISA probe code trys to determine all of the necessary resources to > support the adapter "non-invasively" (i.e. through the registers in the > cards EISA slot address space). The other source of information comes > from issuing a command to the adater through its command register which > is not in the EISA address space. By the time the second set of > information is retrieved, the interrupt has already been set up. > > -- > Justin T. Gibbs > =========================================== > FreeBSD: Turning PCs into workstations > =========================================== >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9701122034.AA0057>