Date: Sun, 05 Jan 97 12:36:42 +0900 From: tedm@agora.rdrop.com To: joerg_wunsch@uriah.heep.sax.de, gibbs@freefall.freebsd.org, freebsd-bugs@freebsd.org Subject: Re: conf/2367: Buslogic SCSI driver bad probe of 742A early revision IRQ and version Message-ID: <9701052114.AA0060@agora.rdrop.com>
next in thread | raw e-mail | index | archive | help
//---------------------------------------------------------------------------- // 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 > > > >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 will attempt to dig into it using Justin's suggestions. The thing is that the machine does work - as long as the IRQ is set to 9, edge-triggered, in EISA-config. This at least should be in the HARDWARE.TXT as a specific mention, simply because it will stop the distributed boot floppy image cold during installation unless the card is set to these settings. For that matter, AHA2740's are only $100, and if I was advising anyone else what to do I'd tell them to ditch this card and buy another! The only reason I'm interested in pursuing this is because I know that if the problem is at least documented with the Project, that in the future someone else with less patience than me with similar hardware will not go blaming FreeBSD when they try their first installation and it fails on them. By the way, with an installed system running, is there any way to recompile the kernel to force selection of a specific interrupt during the eisa-probe? I know how to do it during the ISA bt0 probe, but I don't think this is going to help much. > 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. > I hadn't thought of looking into the eisa-config file for this. I'll see what I can do with it! I know that there are multiple revisions of the eisa-config file. I actually sent in information about the BusTek/Buslogic 742A early in 1996, concerning the different firmware revisions, that info is currently in the FAQ. It originated from this machine, from when I first loaded 2.1 on it, so I know all about the firmware revisions for the 742A, and this card is running the most current firmware it can. I am guessing that if it's a mismatch in the EISA mapping, it is because the probe code was written with a post REV-G 742A card. Buslogic changed something pretty basic between card revisions A-G, and H-onwards, and currently maintains two "current" sets of firmware for the 742A cards, a "pre-rev-H" and a "post-rev-H". Of course, I have a "pre-rev-H" card! :-) > 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. > I understand this, although I'll refrain from asking the obvious question of why bothering to issue the command to the adapter through its command register if it's already been finalized from the eisa-probe. It's probably easier. ;-) Thank you both very much for your suggestions! If I can figure this out, I'll let you know and you can then decide if you want to change the eisa-probe code, or just let it stand and document what needs to be changed. I am also not adverse to UPSing the machine to and from someone if there is interest in doing that, although the thing weighs like it's case is made out of cast iron plates.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9701052114.AA0060>