pre10 on a 2940u2w still shows BRKADRINT

[Robert G. Brown]

On Fri, 18 Sep 1998 felix at halef.rhrz.uni-bonn.de wrote:

> Hi,
> I've got the same problem here with a standard kernel 2.0.35 patched with
> the pre10. However, the those errormessages (0x17 1.time 0x1 after that) do
> show up only after reset, when the machine is warm. Turning off power for a
> while helps. While the system is up, i can't see any problems.
> My System is a P2 Asus P2BS.
> 
> On Thu, Sep 17, 1998 at 04:01:54PM -0700, Neil Magedman wrote:
> > 
> ...
> > I installed pre10 using the the rpm kernel-* files.  After an initial
> > hurdle of not having an initrd prepared (the pre5 was monolithic), I ran
> > 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.

I have a pretty good "laboratory" here in that I have a large number of
identical systems (Dell Poweredge 2300's with the same CPU, memory, bus,
cards, and disks).  As of the linux 5.1.0pre10, I seem to be able to
boot and run nearly all of them.  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.

   rgb

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu




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