*BSD News Article 27983


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
------------------------------------------------------------------------------