Linux-kernel mailing list archive 1999-23,: Re: Oops in 2.3.X, 2.2.X, and 2.0.3X with FENRIS and NCR53c875 SCSI Driver

# Re: Oops in 2.3.X, 2.2.X, and 2.0.3X with FENRIS and NCR53c875 SCSI Driver

Gerard Roudier (groudier@club-internet.fr)
Fri, 11 Jun 1999 21:54:36 +0200 (MET DST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Jan Kara: "Re: Quota lockup on quotaon() with patch in 2.2.9"
- Previous message: Alex Belits: "Re: generalizing khttpd"

Jeff,

On Thu, 10 Jun 1999, Jeff Merkey wrote:

> Gerard,
>
> More info. The address on the analyzer trace appears to be a DSP register.

Could you stop a minute please and think a bit.

You just let me know the first info that may have some relevance. I mean
that it is the DSP register that seem to have been wrongly spotted.
Nobody, even god, is able to give you any help with such a few
informations.

On the other hand, you have sent to the list a mail from me that was
_private_. That's nothing but extreme _bad_ taste.

If you want to solve the problem by yourself, then do it silently, please.
But if you want some help, then let me tell you that you are not on the
right way to get any, at least from me.

> What looks like happened is that someone wrote some state into memorty then
> hit the DSP register to initiate a SCSI SCRIPTs operation, then the driver
> spun off into oblivion. This box we have a very new, and a lot of stuff is
> broken on it besides this. It's a very new PIII system, and We have
> problems with some of the hardware (Intel EtherExpress cards don't work
> properly -- bus timing problems). There may be a config conflict that's
> messing with your driver. I will look at it some more. This may be a case
> where Intel shipped buggy chipsets and we had the misfortune of getting one
> of these boxes.
>
> Is this enough detail for you?

NO. That's just prose that does not help me at all. For the moment, the
_only_ info I noticed from you about your problem is that it seems that
the DSP register has been victimized by some spurious DMA.
Such a cause has great chance to break everything.

About the Intel Chipset, you can download Errata Listings (Specification
Update) from the Intel site. Perhaps some info is already available
about your chipset.

Did you check that all your hardware was properly assembled?

Did you give a try to a minimal configuration as this one?
You system should be able to boot with only a boot device installed.
You should try to only configure the PCI device that deal with your
boot device (remove all other PCI devices if possible and/or donnot
configure any driver for them) and observe if the problem still
occurs under some load.

Gérard.

> Jeff
>
> ----- Original Message -----
> From: Jeff Merkey <jmerkey@timpanogas.com>
> To: Jeff Merkey <jmerkey@timpanogas.com>; Gerard Roudier
> <groudier@club-internet.fr>; <linux-kernel@vger.rutgers.edu>
> Sent: Thursday, June 10, 1999 4:55 PM
> Subject: Re: Oops in 2.3.X, 2.2.X, and 2.0.3X with FENRIS and NCR53c875 SCSI
> Driver
>
>
> >
> > Gerard,
> >
> > I was not spending a lot of time with this right now becuase I was trying
> to
> > get FENRIS tested on as much hardware as possible prior to dumping the
> code
> > to our FTP server, but I will have some time tommorow to look at this in
> > more depth if this would be helpful after I put the tarball up on our ftp
> > server. What do you want me to look at next?
> >
> > Jeff
> >
> >
> > ----- Original Message -----
> > From: Jeff Merkey <jmerkey@timpanogas.com>
> > To: Gerard Roudier <groudier@club-internet.fr>;
> > <linux-kernel@vger.rutgers.edu>
> > Sent: Thursday, June 10, 1999 4:51 PM
> > Subject: Re: Oops in 2.3.X, 2.2.X, and 2.0.3X with FENRIS and NCR53c875
> SCSI
> > Driver
> >
> >
> > >
> > > Gerard,
> > >
> > > I am using an American Arium Logic analyzer (leased). The bus trace
> shows
> > > an errant DMA from a busmastering device that trashed memory in my
> system
> > (I
> > > was running a bus trace to track this down). The bus activity indicates
> > > that a device mapped to a very odd address in the system memory map
> > > (0xB0000000) was doing something when the DMA occurred. I'm an old
> > hardware
> > > guy who converted to software, but I'm very proficient with hardware
> > > analysis tools, in fact, most of my SMP debugging is done with a logic
> > > analyzer with an inverse assembler. I also wrote SCSI scripts years
> back
> > > for the NCR 53C720 (we used SCSI for clustering) so I'm pretty familiar
> > with
> > > "buggy" SCSI scripts and I've seen this type of behavior before. There
> > was
> > > also a reset on the SCSI device which would indicate a reselction was in
> > > process (saw a test unit ready and inquiry command with a status of '4'
> > > being returned from the device if this is helpful.[also have a SCSI
> > > analyzer(leased)]) .
> > >
> > > I have not looked through your scripts for the driver and don't have a
> > > scripts compiler (does one ship with Linux)-- but could. Should I do
> this
> > > next?
> > >
> > > Jeff
> > >
> > > ----- Original Message -----
> > > From: Gerard Roudier <groudier@club-internet.fr>
> > > To: Jeff Merkey <jmerkey@timpanogas.com>
> > > Sent: Thursday, June 10, 1999 3:34 PM
> > > Subject: Re: Oops in 2.3.X, 2.2.X, and 2.0.3X with FENRIS and NCR53c875
> > SCSI
> > > Driver
> > >
> > >
> > > >
> > > >
> > > > On Thu, 10 Jun 1999, Jeff Merkey wrote:
> > > >
> > > > > Alan,
> > > > >
> > > > > None of the other setups produce the "..could net get a free page.."
> > > > > message. This looks like a subtle race condition with this
> particular
> > > scsi
> > > > > driver. I will try some other scenarios.
> > > >
> > > > Dear Jeff,
> > > >
> > > > The first thing you should want to do prior to posting any diagnostic
> of
> > > > yours to the kernel list could be to, at least, check that you are not
> > > > just annoucing some triviality or claiming some stupidity. Note that I
> > > > didn't see any triviality in your postings.
> > > >
> > > > The second thing it to provide maintainers with relevant traces, logs,
> > > > source code, scripts that triggers the problem, accurate description
> of
> > > > the problem, etc ... Your opinion may be interesting, but only if is
> > based
> > > > on relevant observations, and, by the way, something that is just
> > claimed
> > > > as "looking like subtle ..." has nothing to do with relevance, in my
> > > > opinion.
> > > >
> > > > Now, if you really are quite sure that the SCSI driver is the thing
> that
> > > > breaks your system, I invite you to take biggest possible gun and and
> > shot
> > > > it immediately.
> > > >
> > > > I am the maintainer of some driver that you may have used on your
> > system.
> > > > Most of reports from people that experience problems when using such
> > > > drivers generally accused the driver first. The reality _is_ that most
> > > > of the time, the problem has been proved to be elsewhere.
> > > >
> > > > A kernel list is public. When you claim 'I think something is broken'
> > > > in public, then, a not negligible number of readers may just beleive
> you
> > > > or just want to beleive you.
> > > >
> > > > Report the problem as you observe it, please, and avoid comments that
> > > > are just bare claims. Thanks.
> > > >
> > > > Btw, the URL that hosts driver updates is the following:
> > > > ftp://ftp.tux.org/pub/roudier/drivers/
> > > >
> > > > Gérard.
> > > >
> > > > >
> > > > > Jeff
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> > > > > To: Jeff Merkey <jmerkey@timpanogas.com>
> > > > > Cc: <jmerkey@timpanogas.com>; <linux-kernel@vger.rutgers.edu>
> > > > > Sent: Wednesday, June 09, 1999 5:32 PM
> > > > > Subject: Re: Oops in 2.3.X, 2.2.X, and 2.0.3X with FENRIS and
> > NCR53c875
> > > SCSI
> > > > > Driver
> > > > >
> > > > >
> > > > > > > Also shows up single processor (different machine, same chipset
> > > 53C875).
> > > > > =
> > > > > > > Looks like a possible SCSI Scipts error. FENRIS, unlike UNIX
> > FS's
> > > will
> > > > > =
> > > > > > > talk to more than one disk or partition concurrently since a
> > volume
> > > can
> > > > > =
> > > > > > > have multiple segments strip[ed across several drives. May be
> > > exposing
> > > > > =
> > > > > > > some timing condition with the way I am calling breada abd
> bread.
> > > > > >
> > > > > > The raid code already does that kind of concurrency. Now the
> > important
> > > > > clue
> > > > > > is probably
> > > > > >
> > > > > > > More on this -- am also getting "..could not get a free
> > page...".
> > > =
> > > > > >
> > > > > > This indicates a memory allocation failed. That means its more
> > likely
> > > > > someone
> > > > > > doesnt check a get_free_page/kmalloc return and continues
> blissfully
> > > into
> > > > > > oblivion mode.
> > > > > >
> > > > > > Could be the driver fs or scsi layer. Are your other test setups
> > > producing
> > > > > > a "free page..." message too ? (ie the working ones)
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > -
> > > > > To unsubscribe from this list: send the line "unsubscribe
> > linux-kernel"
> > > in
> > > > > the body of a message to majordomo@vger.rutgers.edu
> > > > > Please read the FAQ at http://www.tux.org/lkml/
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
>
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Jan Kara: "Re: Quota lockup on quotaon() with patch in 2.2.9"
- Previous message: Alex Belits: "Re: generalizing khttpd"