[4576] in linux-scsi channel archive
Re: [REPORT] Adaptec and SMP problems on 2.0.35
daemon@ATHENA.MIT.EDU (Dancer)
Tue Aug 18 21:35:09 1998
Date: Thu, 20 Aug 1998 22:16:19 +1000
From: Dancer <dancer@brisnet.org.au>
To: Matthew Hawkins <matt@mail.goldweb.com.au>
CC: linux-scsi@vger.rutgers.edu, linux-kernel@vger.rutgers.edu
Matthew Hawkins wrote:
>
> On Tue, 18 Aug 1998, Ricardo Galli wrote:
>
> > PS: YES I "Read all The Fine Manuals", mail archives, FAQs and howtows,
> > there are many "indications" that possibly the adpatec driver/hardware is
> > the guilty of the SMP lockups, but there is no a definitive solution.
>
> Not only in SMP, twice in the past week my server-from-hell, which is
> uniprocessor, has also locked hard with scsi errors. The controller is
> an Acraptech 2940UW. I can't recall the exact errors off-hand (I'll check
> the logbook when I get into work) I think one was a problem resetting the
> scsi bus after some other error, the second one was different iirc.
>
> I get the feeling that the various corruptions, general protections, kernel
> oopses et al. that I've posted to this list in the past month are now scsi
> related (I've already eliminated CPU, L1/L2 cache and power through hardware
> testing - which imho leaves the ram and the scsi controller).
We have had similar, with a dual PPRO system. We turned off SMP, which
did not noticeably help. We achieved stability only when we disabled the
second CPU in the BIOS.
We've got a 7800UW and a 2940UW, two 3com ethercards, and one EEPro100.
I found it curious that even the UP kernel (2.0.32) was not stable until
the second CPU was disabled. Physical design flaw? BIOS problem? Don't
know. I don't have the luxury of extracting a machine from production,
or getting one solely for testing. Contractual junk.
Any inspirations would be appreciated. We could really do with the
second CPU, and the two CPUs+Adaptec seems to be a big lose, regardless
of whether we're SMP or UP.
D
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
