Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!uniwa!DIALix!DIALix!not-for-mail From: julian@perth.DIALix.oz.au (Julian Elischer) Newsgroups: comp.os.386bsd.questions Subject: Re: BT742 driver changes... (was PCI....) Date: 2 Mar 1994 14:40:54 +0800 Organization: DIALix Services, Perth, Australia. Lines: 140 Sender: root@melbourne.DIALix.oz.au Message-ID: <2l1cdm$gs9$1@melbourne.DIALix.oz.au> References: <baier.2.000933A6@risc1.ccso.cim.ch> <michaelv.761848129@ponderous.cc.iastate.edu> <CLLM44.3M2@obiwan.uucp> <michaelv.761882391@ponderous.cc.iastate.edu> <CLuvGu.5Lv@flatlin.ka.sub.org> <michaelv.762403965@ponderous.cc.iastate.edu> NNTP-Posting-Host: melbourne.dialix.oz.au In <michaelv.762403965@ponderous.cc.iastate.edu> michaelv@iastate.edu (Michael L. VanLoon) writes: >In <CLuvGu.5Lv@flatlin.ka.sub.org> bad@flatlin.ka.sub.org (Christoph Badura) writes: >>In <michaelv.761882391@ponderous.cc.iastate.edu> michaelv@iastate.edu (Michael L. VanLoon) writes: >>>All of the current models should have this feature. Basically, it >>>uses the mailboxes in a round-robin fashion. This breaks the old >>>driver because the card starts looking for disk transactions where >>>there are only empty mailboxes and it never gets around to the >>>intended transactions since the driver doesn't write them out in >>>round-robin order. The old code relied on undocumented behaviour. Atushi Murai rewrote the mailbox code to correctly handle new devices. This new code was posted and also included into the FREEBSD current code, however I cannot say whether it ever made it into NETBSD-0.9. (as I don't have it here). >Julian's "new" SCSI code says the round-robin mailbox scanning feature >is disabled by default. This indicates to me that older firmware made >it an option you turned on. My "BT-742A EISA SCSI Host Adapter >Technical Reference Manual", which is less than a month old (copyright >1983), says ^ 9? I rely in Atushi on this, but he assured me that the new undocumented command to turn on/off the old/new behaviour does exist, and I've seen the driver working on old and new boards. If the board is old, the special command is just ignored. for further clarification on this point, please write to amurai@spec.co.jp and get his interpretation on how this works, as I am rather hazy on it. I do know that for one version of proms however, Buslogic changed the behaviour, and we had to change the behaviour of the driver to suit. As I dont get to read news very often, please keep me up-to date via mail to julian@dialix.oz.au (I will be here for 2 more weeks) or to julian@tfs.com > After processing an outgoing mailbox, the BT-742A will scan > for another active entry beginning with the outgoing mailbox > following the one just completed. The host can ensure that the > BT-742A will always find the next command with minimum overhead > by placing commands in the outgoing mailboxes in consecutive, > round-robin order. The BT-742A will look for additional outgoing > mailbox entries until it finds an empty outgoing mailbox, at > which time it will stop scanning. It will start scanning again > when the host issues a Start Mailbox command to indicate that > another entry has been made. the original undocumented behaviour was to scan ALL mailboxes, starting with the next, so it would always find the new item. >The wording implies this is not an option, and no command in the >manual is provided to turn round-robin on or off. It's undocumented. > In addition, it >says it will "look for additional outgoing mailbox entries until it >finds an empty outgoing mailbox, at which time it will *stop >scanning*." It doesn't take long to figure out how this will easily >break the old allocation method in the old NetBSD bt742a.c driver. yes, but the new code posted to the net a year ago would fix this. >>In any case, from my >>inspection of Julian's code I'd say that the code deals properly with >>this situatation by issueing a Start Mailbox Command opcode to the >>adapter whenever it places a request into an outgoing mailbox. >Your inspection is either wrong, or you're looking at the wrong driver >code. As I have mentionned before. NetBSD did not pick up newer changes to the SCSI system and you are both dicussing DIFFERENT versions of the driver. > The previous NetBSD code breaks on new firmware in a very >obvious and repeatable fashion. My controller has been running for >weeks flawlessly on my updated driver with no problems whatsoever. I >could not even boot off the old driver. And I'm not the only one >who's experienced this problem. Others have fixed it by replacing >their firmware roms with older firmware versions. Why do you think I >spend my over-committed time writing the new driver? My card *didn't >work* with the old driver! I understand this, but the fixes have been around for a long time. I would be happy to see your changes (mail them to me) but they should not be needed for NetBSD-magnum (has the new SCSI code) or for FreeBSD. The old 742a driver (post NetBSD-split-off) should also have this fix and should be mostly NetBSD-0.9/current compatible. >>The fact that older as well as recent adaptors work flawlessly with >>Julian's code makes me wonder what this alleged change in firmware >>would be about. >But recent adaptors *don't* work flawlessly with Julian's older code >(which is what NetBSD is currently using). The drivers that were newer than the NetBSD split-off do. This is not a mystery, we just now have two sets of fixes for this problem instead of one. If anyone had asked me about the problem I could have mailed them an appropriatly fixed driver since about Oct 92. Still at least we now have an extra SCSI guru to pester when things don't work.. 8-) >>>I saw a comment in Julian's drivers that said this >>>feature appeared first at firmware version 3.31, but it may have been >>>optional back then -- it is now the default behaviour in any current >>>cards. Yes this is in the NEW driver. >>I was unable to find a comment to this extend in the NetBSD and you >>driver. I wonder what it said. Anyway, the behavior never was >>optional. No, it's not in the OLD (NetBSD) driver. >See above. >>>I have a new bt driver that fixes this for NetBSD-current. good, though I'd rather see the NEW scsi code ported to NetBSD because it's a lot better. (several people have said they are running it but no-one has claimed to have ported it well enough to release) (for all I know it may just run). >What more can I say? Look at the driver in NetBSD. Remember the >driver in FreeBSD is not the same (if that's where you looked). No, but there was an intermediate version that was released that was close to the NetBSD version, that had the fixes in it and which coild have been used to make a NetBSD version of the fixed driver. >------------------------------------------------------------------------------ julian