pre10 on a 2940u2w still shows BRKADRINT

[Doug Ledford]

Robert G. Brown wrote:

> > > into a similar BRKADRINT bug.  Whereas the pre5 would loop with
> > >     Data-Path Ram Parity Error
> > >     PCI Error Detected
> > >     (scsi 0) SEQADDR = 0x50
> > > the pre10 kernel would loop with
> > >     Data-Path Ram Parity Error
> > >     (scsi 0) SEQADDR = 0x17d        [the first time]
> > >     (scsi 0) SEQADDR = 0x1  [subsequent times]
> > ...
> 
> The problem with a relatively new driver is that it is difficult to
> separate out problems with the driver, problems with the hardware (yes,
> some hardware IS just plain old defective), problems with the firmware,
> and problems with the attached system BIOS and conflicts with other
> devices on the PCI bus.

In this case, I think this is a problem with the driver.  However, just what
that problem is isn't known yet :)  I'm currently leaning towards the idea
that I haven't *completely* written every memory location on those cards,
and if you want to be completely anal about the Adaptec docs, you are
suppossed to write something to every location on those cards to initialize
the parity bits.  So my next driver version will be putting in code to
hopefully hit more of the locations and get things set up properly.  You
never know, maybe this error is from a parity error in the data fifo. 
Anyway, as soon as I can re-produce the problem here, then I'll get it
fixed.  I'm working on that :)

> cards, and disks).  As of the linux 5.1.0pre10, I seem to be able to
> boot and run nearly all of them. 

Excellent :)  I was hoping more of your machines would start working with
pre-10.

> 2 out of 16, however, remain
> incalcitrant and resist my every effort to force them to function.
> Today (just for the list record) on the advice of the Dell Service Guy I
> jumpered the motherboard to force a clear of the system NVRAM and power
> cycled it, in case its internal memory was somehow corrupted and this
> was interfering with system initialization.  I am truly sorry to say
> that it had no effect.  I'm still getting the Data-Path Ram Parity
> Errors in loop to infinity immediately after the sequencer download,
> right when the system attempts to determine the attached devices on both
> systems.  I haven't retried the freebsd latest-cam-snapshot boot.flp
> re-downloaded at Justin's suggestion (actually, the freebsd site is
> pretty busy and getting through is slow:-) but still plan to do so.
> 
> However, working through the list above, it does seem like it is getting
> more likely that in my case (and possibly in others as well) the problem
> really is a hardware problem (or at least, not the driver anymore).
> Looking over the alternatives, I recall that once upon a time Adaptec
> was rather notorious for sneaking onboard SCSI BIOS revisions into their
> production line so that a driver would work and then fail.  Is it known
> that the bios for 7890's has been stable for a while at this point?  I
> couldn't find anything obvious on their website, but they do have a form
> that admits the possibility.
> 
> I'm going to have a Dell service human out here on Monday; I may try to
> talk them into arranging a motherboard swap to see if that fixes the
> problem (the 7890 is onboard).  Or perhaps he/she will have a diagnostic
> disk of some sort -- there are virtually no diagnostics available in
> what I got with the system.
> 
> If there IS a good suspicion that it is still a driver problem, I still
> have two good (that is, bad:-) systems that I can try any solutions on.

Well, I still think it's a driver problem.  Essentially, my stance on the
issue is that the driver should be able to work with the hardware regardless
of BIOS bugs since the only thing we really use the BIOS for are just a
*very* select few items (such as the proper state of STPWRLEV in the
DEVCONFIG register).  These are machine/device dependant, so we can't init
those reliably (although pre-11 allows you to pass special params to the
driver to force these settings).  Other than a few things like that, the
driver should be able to work regardless of any BIOS bugs.

-- 

 Doug Ledford  <dledford at dialnet.net>
  Opinions expressed are my own, but
     they should be everybody's.

To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe freebsd-aic7xxx" in the body of the message