Date: Sun, 05 Jan 97 13:14:37 +0900 From: tedm@agora.rdrop.com To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-bugs@FreeBSD.org Subject: Re: conf/2367: Buslogic SCSI driver bad probe of 742A early revision IRQ and version Message-ID: <9701052207.AA0066@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 ------------------------------------------------------- > X-Mailer: Mutt 0.55-PL10 > MIME-Version: 1.0 > Date: Sun, 05 Jan 97 16:27:01 +0100 > From: j@uriah.heep.sax.de > To: tedm%toybox@agora.rdrop.com > Reply-To: joerg_wunsch@uriah.heep.sax.de > Cc: 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. Have you any > indication about other (protected-mode, thus non-DOS) systems probing > the EISA configuration correctly? > I attempted to install NT 4.0 Server on the machine and was unable to get it to write out a bootstrap that it could read. NT churned through it's entire install process, then when the machine rebooted it came up with the "missing operating system" message. I think this is because the hard disk is this DEC full-height 5.25 2 gig unit, and the SCSI bios cannot do a translation that is meaningful because it's too large. NT didn't have a problem reading and writing out data to the disk, though. I could try booting with OS/2, but OS/2 is like Unix, the bootstrap must reside under 1024 cylinders. Worse, the OS/2 kernel on startup establishes a DOS VDM, and starts processing it's CONFIG.SYS, and loads everything through virtualized BIOS code until the actual disk driver .ADD file is loaded, then switches over to the protected-mode disk driver. in short the kernel loads the disk driver from the filesystem, so it needs to know about disk geometry, which means that your translated geometry cannot be some pie-in-the-sky fake geometry. I doubt it would work properly. > > 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. > Besides, who uses the floppy drive under Unix anyway? ;-) > > > > 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.) > Good, there's hope at least. I have two other questions for you, if you don't mind answering. The first is that this machine has an Archive Anaconda 1.3GB QIC SCSI tape drive in it, that is sensed by the bt driver and listed in the probe. I can insert a DC600A tape in it, run "mt status" and the drive knows that it is a QIC-120 tape. Similarly, a DC6150 is sensed as a QIC-150, and a DL 9135 is sensed as a QIC-1350. The problem is with all those tapes, the available modes listed are all Density = 0x00, Blocksize variable, and when I attempt to read or write anything from the tape I get NOT READY errors. I think this requires that I add a listing for this drive in the "Rogue's gallery" in the st.c driver, to get it to properly set up the modes. Unfortunately, I don't have the spec sheet that came with this drive, but I remember it and it was very sparse. (basically a relisting of what you can already read about using "man mt") Also, I don't understand the format of the gallery, is there any documentation on how to do this around? The other question is, I have setup X on this, it has a ET4000w32 board with 1M of ram on it. I have tried starting the server in any color plane other than 8bbp using an .xserverrc file, and I get an error message "ET4000W32: Unsupported depth (16)" (for example) Any ideas or suggestions? Thanks, Ted
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9701052207.AA0066>