Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!bruce.cs.monash.edu.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!vixen.cso.uiuc.edu!newsrelay.iastate.edu!news.iastate.edu!ponderous.cc.iastate.edu!michaelv From: michaelv@iastate.edu (Michael L. VanLoon) Newsgroups: comp.os.386bsd.questions Subject: Re: BT742 driver changes... (was PCI....) Date: 2 Mar 94 15:49:06 GMT Organization: Iowa State University, Ames, Iowa Lines: 155 Message-ID: <michaelv.762623346@ponderous.cc.iastate.edu> 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> <2l1cdm$gs9$1@melbourne.DIALix.oz.au> NNTP-Posting-Host: ponderous.cc.iastate.edu cc: julian@tfs.com In <2l1cdm$gs9$1@melbourne.DIALix.oz.au> julian@perth.DIALix.oz.au (Julian Elischer) writes: >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). Right. NetBSD never got this update, but FreeBSD did. >>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? Yes, 1993. Oops. :-) (Talk about living in the past...) >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. I saw this command in the newer code, but it wasn't documented in my manual, so I was a little leary of using it. Sometimes undocumented features dissapear at the least appropriate times. >> 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 wording implies this is not an option, and no command in the >>manual is provided to turn round-robin on or off. >the original undocumented behaviour was to scan ALL mailboxes, starting with >the next, so it would always find the new item. This is what I figured, which worked fine with the older firmware, but which broke on the newer firmware. >> 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. Unfortunately, I never saw this update, since my BusLogic card is only a month or so old, and I wasn't interested in any specific SCSI driver before then. >>>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. Correct. This is why I used the word "NetBSD" so much in my original post. Yet, someone still managed to think I was talking about the FreeBSD driver. Go figure. >> 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. Unfortunately, anyone who has seen the magnum code hasn't come out alive to tell about it. ;-) Honestly, magnum has little bearing on the user community at large who are using 0.9 or NetBSD-current. Yes, magnum has your new code in it which doesn't suffer from this bug anymore, but none of us are running magnum, so I needed a fix that works for me now. >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. I asked a bunch of times on several different forums before rewriting the driver, to be honest. But at that point I didn't know what the problem was, all I knew was that my card didn't work. It's possible that you didn't realize NetBSD had the pre-round-robin bt driver still, at that point. Now we all know. :-) >Still at least we now have an extra SCSI guru to pester when things >don't work.. 8-) OK, I suppose I can handle this. :-) Still, I think "SCSI guru" is a little more than what I'd consider myself. >>>>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). I'd like to see the new code too. My fixed driver is only an interum band-aid until the new SCSI code arrives. There is a person who has 90% of the work done, but we're going to have to wait til he gets it finished, I guess. I hope you understand that I wasn't criticizing your SCSI code when I was blasting your old driver in NetBSD-current. When that driver was written, it was adequate for the job. And, it isn't your fault that it never got upgraded. Now we have a fix that I wrote that will get us by until your newer code gets integrated into NetBSD. >julian --Michael -- ------------------------------------------------------------------------------ Michael L. VanLoon Project Vincent Systems Staff michaelv@iastate.edu Iowa State University Computation Center ------------------------------------------------------------------------------