Date: Mon, 19 Jul 2004 13:21:56 -0300 From: "Petriz, Pablo" <ppetriz@siscat.com.ar> To: "'Todd Denniston'" <Todd.Denniston@ssa.crane.navy.mil>, "Jurzitza, Dieter" <DJurzitza@harmanbecker.com>, "'tom@uwm.edu'" <tom@uwm.edu> Cc: "'aic7xxx@freebsd.org'" <aic7xxx@freebsd.org> Subject: RE: Promise RM8000 news [was Re: aic7xxx] Message-ID: <1CEC5A75042ED51180E300A024E99257AD8378@zeus.sc.com>
next in thread | raw e-mail | index | archive | help
Good news!? Ok, something good is happening when the tower has 1 disk = less. I too have the tower functioning OK since i removed one disk!=20 My configuration is disk 1 to 6 on raid5, disk 7 spare, empty bay 8.=20 The removal was only to use that disk for backup purposes on other = machine, but since that the tower is running ok. We rebuild the array, create a filesystem over the 1.5TB of the raid5, run badblocks over the entire = raid and it works! Then we began to feed the raid with data and it's = working. The other phisycal change was the serial cable. I was monitoring the = tower from a second Windows machine in order to use webpam. Now i have the = cable connected to the same server that has the scsi cable and i'm checking = via minicomm (thanks Todd). I don=B4t think the serial cable could affect = it... So till next fail, we can say that the problem is to have 8 disks in = the=20 tower. Other thing to consider: One of my tests was to use an old SCSI card on = my server, and it works fine; but it all happens at the same time: = installing the old SCSI and removing the disk! Well, now the server has the same=20 configuration that has when it failed (using the on board SCSI), so the = big change IS the disk removal. Lets wait and keep in contact. PABLO > -----Mensaje original----- > De: Todd Denniston [mailto:Todd.Denniston@ssa.crane.navy.mil] > Enviado el: lunes 19 de julio de 2004 12:26 > Para: Jurzitza, Dieter > CC: 'tom@uwm.edu'; Petriz, Pablo > Asunto: Promise RM8000 news [was Re: aic7xxx] >=20 >=20 > "Jurzitza, Dieter" wrote: > >=20 > > Hi guys, > > the good thing over all: we share the same problems. The=20 > bad thing: it does > > not help. Did anybody of you get into a reliable operation=20 > of the promise > > array? Do you see the crash of the array in=20 > /var/log/messages when your > > system fails? Do you see any influence whether you run SMP=20 > / single CPU > > mode? > > Thank you for any comment. I am not subscribed to the=20 > aic-mailing list, this > > is why I write to you directly. > > Take care > >=20 > > Dieter Jurzitza > >=20 > > -- > <SNIP> > Good news/Bad news. >=20 > Good news > After I removed from the array a drive which I know to be bad=20 > [1]. I know it > should not have made any difference though, because the drive was = only > physically in the array, it was not locked in so there should=20 > not have been > power or communications to it. Since I have removed it, I=20 > put the system in a > configuration where before it would last ~16 hours max before=20 > lock up, and yet > it has been running for 23 days. The only change is the=20 > physical removal of > the bad drive! >=20 > It both thrills me and make me mad to find out that a drive=20 > just setting > in the array with no power could cause these problems! >=20 >=20 > Bad news > This seems to be working for me, and neither of you reported=20 > having a bad > disk. Plus I still think this is something which should not=20 > have affected the > array AT ALL. >=20 > I also changed out the cables to some Belkin F2N1066-06-T [2]=20 > but I was still > able to get the lockup until I removed the drive. >=20 > [1] at least from the perspective of the badblocks program. > [2] http://www.cdw.com/shop/products/default.aspx?edc=3D97924 >=20 >=20 >=20 > --=20 > Todd Denniston > Crane Division, Naval Surface Warfare Center (NSWC Crane)=20 > Harnessing the Power of Technology for the Warfighter >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1CEC5A75042ED51180E300A024E99257AD8378>