Date: Thu, 30 Nov 2000 22:18:47 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: Darren Joy <darrenj@uk.uu.net> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Problems with SYM and DC390W in 4.2 Release Message-ID: <Pine.LNX.4.10.10011302151020.1528-100000@linux.local> In-Reply-To: <Pine.BSF.4.10.10011301855110.8586-100000@yukon.cam.uk.internal>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 30 Nov 2000, Darren Joy wrote: > Some Background : >=20 > I had a machine, running 3.2 Release, quite happily, without problem sinc= e > that release came out. For reasons which I won't go into and which aren't > relevant IMHO, it stayed as plain 3.2 until this week, when I decided to > purge that and install 4.2 Release, using the same hardware. >=20 > Some Kit : >=20 > Intel PII > Abit BH6 mb > Tekram DC390W ( running from 50 pin interface ) > Seagate 4GB Barracuda > Conner CFP2105S 2GB >=20 > and later a >=20 > Fujitsu 9GB SUN disc >=20 > Some Story : >=20 > I removed the Barracuda to use in another machine, as this one would now > be a workstation only. I tried to install 4.2, first via CD, and later vi= a > FTP. The install got so far, then totally hung the machine, always when > installing the ports or the src distributions. The second VTY revealed > some interesting error messages along the lines of : >=20 > sym0:0: message d sent on bad reselection. > sym0:0: message d sent on bad reselection. > sym0:0: message d sent on bad reselection. > sym0:0: message d sent on bad reselection. > <repeat lots> The driver is reselected by TARGET #0 for a IO that does not exist in the= =20 task list as seen by the driver. > sym0:0:control msgout: 80 20 27 d. > sym0:0:control msgout: 80 20 1d d. > sym0:0:control msgout: 80 20 51 d. > sym0:0:control msgout: 80 20 33 d. > sym0:0:control msgout: 80 22 59 d. > sym0:0:control msgout: 80 22 25 d. The driver is aborting (under behalf of CAM) tasks that had been queued to TARGET #0. > And I see this problem every time. If I omit the ports and source > distributions, I can get it to install before I see the problem, but when > I try to add them afterwards, same problem, same errors. I have formatted > and verified the disc from the SCSI BIOS, and can find no errors on it. I > have also tried disabling tagged-commands for this drive, no change. >=20 > I offer this disc as doorstop #1. >=20 > The Barracuda is dead too, won't report any drive statistics, although it > will spin up. This though I am willing to entertain could have been > damaged through a dodgy PSU ( in an altogether different machine from the > one in discussion ), but it certainly won't work in this machine at the > moment. >=20 > I offer this disc as doorstep #2. >=20 > Then I plugged in a Sun multi-pack containing the Fujitsu, to see if the > install went ok on that, my thinking being that if the install succeeded, > the culprit was a dodgy Conner disc ( which is old now ). >=20 > The install completed without hitch, all distibutions went on fine. Then > the reboot, and the SCSI controller gets no response from the Fujitsu. If > I go into the SCSI BIOS, I can see it and read the stats on it, but on > booting, nothing, just hangs the machine, never gets past that SCSI ID. S= o > whatever FreeBSD did to that disc during the install, the DC390W couldn't > see it afterwards... The software killing drives is very unlikely, unless they were close to die naturally. Btw, can you retrieve at least some kernel boot messages that succeeds. Such info is far more useful than long literature. > A low level format of the Fujitsu made it show up again in the scan, > however, doesn't solve my problem, and low level formatting of the Conner > did not help either. >=20 > My question I guess is, are there known issues in 4.2 with the SYM driver > and the DC390W? Should I risk another drive becoming a doorstop? This > combination worked fine on Tuesday when it was happily running 3.2, so I > am not keen to believe this is chance.. Depends on how many doors you need to stop using dead hard disks. :o) If you really think it is the driver that killed your disks, then you can simply edit your kernel config and replace it by `ncr' that was the driver= =20 you probably were using under FreeBSD-3.2. > If it's a dodgy Conner disc, I am happy with that, but using a different > disc rendered that disc inopperable as well, so I am suspicious of the > controller/driver. > > Can anyone offer any information to end my torment?=20 > ( I have had a bad week for hard-discs.... ) I understand. But actual causes may well be quite unrelated to the driver/hba pair, but have been just bad luck or unlikely bad things that happened at the time. Regards, G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10011302151020.1528-100000>