*BSD News Article 27965


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: PCI SCSI for NETBSD
Date: 28 Feb 94 02:52:45 GMT
Organization: Iowa State University, Ames, Iowa
Lines: 104
Message-ID: <michaelv.762403965@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>
NNTP-Posting-Host: ponderous.cc.iastate.edu

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.

>I presume you meant it *scans* the mailboxes in a round-robin fashion.

Right, and it *stops* scanning on the first empty mailbox it finds.
Since the old NetBSD driver always allocats mailboxes from the top
down, and makes no effort to keep the free list in round-robin order,
the card can start looking for mailboxes where the driver is not
writing them and can stop processing disk commands while the driver
thinks things should be happening.

>That's a very old feature.  In fact, this at least dates back to the
>AHA1542A.  This was clearly documented to be the case as of 12/31/91
>(the oldest 742A technical reference manual I have at hand) and that's
>well before the 742A driver was written.

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

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

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

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

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

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

See above.

>>I have a new bt driver that fixes this for NetBSD-current.

>I don't know what the your modifications are supposed to fix.  From
>looking hard at the diffs all I can say is that the mods for sure burn
>a lot more cycles in the driver.  And, to me anyway, for no apparent
>reason.

They use extra cycles where necessary.  They don't burn an
extraordinary number of cycles.  Overall, they should be more
efficient than the older driver since they don't scan *every* mailbox
anymore -- only the busy ones until an empty one is found.

>I'd very much like to hear a detailed explanation of the new behavior
>and why your mods fix it.

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

-- 
------------------------------------------------------------------------------
  Michael L. VanLoon                           Project Vincent Systems Staff
  michaelv@iastate.edu              Iowa State University Computation Center
------------------------------------------------------------------------------