Date: Sun, 5 Jan 1997 16:27:01 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: tedm%toybox@agora.rdrop.com Cc: freebsd-bugs@FreeBSD.org Subject: Re: conf/2367: Buslogic SCSI driver bad probe of 742A early revision IRQ and version Message-ID: <Mutt.19970105162701.j@uriah.heep.sax.de> In-Reply-To: <9701042233.AA0056@agora.rdrop.com>; from tedm@agora.rdrop.com on Jan 4, 1997 14:10:44 %2B0900 References: <9701042233.AA0056@agora.rdrop.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Have you any indication about other (protected-mode, thus non-DOS) systems probing the EISA configuration correctly? > There is also a smaller SMC ASIC visible, it is a FDC37C65C This > is obviously the floppy disk controller chip, incidentally the fd0 > probe I sent in on the pr comes up with an "unknown chipset" on it. > Perhaps this is another thing I should send in on a separate > send-pr? No need. If i rewrite the floppy controller code some day, i will reconsider the chipset detection. Documentation about how to detect floppy controllers is sparse and often wrong. The probably best documentation is the Linux driver. :-) There won't happen anything on this front before (since it's a minor bogosity anyway), regardless of how many PRs of this kind are filed. At least not by me, since the floppy controller driver is fairly low-priority. PRs for show-stopper class problems have a higher priority than cosmetic things. > Can you tell me what piece of code is at fault? I'm guessing it's > the EISA probe code, since this problem didn't exist in FreeBSD > before the eisa-probe code was added. No, i can't. I'm not an EISA expert. The attach function for the bt7xx is not very large. It's not surprising that it worked in ISA mode, since it simply had to believe your config statement there. > Perhaps I can try inserting some fprints in it to get some more > data for this? Also, why is the driver being hosed by the > eisa-probe, even when the later driver probe gets the correct > interrupt? Don't ask me. Julian or Justin might be the guys with more knowledge. > One last question I have for you, can this card do sync 10Mbt > negotiation? It did for me, here, i still found an old probe message: uriah /kernel: bt0: targ 0 sync rate=10.00MB/s(100ns), offset=15 uriah /kernel: bt0: targ 1 sync rate=10.00MB/s(100ns), offset=15 uriah /kernel: bt0: targ 2 sync rate= 4.00MB/s(250ns), offset=15 uriah /kernel: bt0: targ 3 async uriah /kernel: bt0: targ 4 sync rate= 4.54MB/s(220ns), offset=08 (Targets 0 and 1 are disks, 2 is a Toshiba CD, 3 is an old SONY SMO optical drive [actually, an ESDI-to-SCSI bridge], 4 is a Tandberg QIC 2.5GB tape.) Did you read the FAQ, btw? It mentions serious problems with various firmware revs of the BusLogic boards. Perhaps your firmware is also buggy? Alas, i can't tell you the firmware rev of my old Bt742A anymore, all messages of this kind are gone. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Mutt.19970105162701.j>