Date: Thu, 28 May 1998 19:49:04 -0400 From: tcobb <tcobb@staff.circle.net> To: "'freebsd-current@freebsd.org'" <freebsd-current@FreeBSD.ORG>, "'freebsd-scsi@freebsd.org'" <freebsd-scsi@FreeBSD.ORG> Cc: "'simon@simon-shapiro.org'" <simon@simon-shapiro.org> Subject: DPT driver fails and panics with Degraded Array Message-ID: <509A2986E5C5D111B7DD0060082F32A402FABC@freya.circle.net>
next in thread | raw e-mail | index | archive | help
I have a DPT3344UW/2 running an external 24GB array. OS is FreeBSD CURRENT circa 5/18/98. I'm running the latest available firmware flash for the card, all on a P5-233MMX with 128MB RAM. Recently I lost a harddrive in my 24GB RAID5 array. The array was configured with a HOT SPARE which should have allowed it to rebuild completely online, with no interruption in service (except some minor slowdowns, perhaps). While the HARDWARE worked well, the DPT DRIVER failed miserably. When my array went into degraded mode, the DPT DRIVER froze access to the partitions. Upon reboot, during device probe, the DPT DRIVER returned a 1 SECTOR (0 MB) sense for the array, despite the fact that the array was operating properly (though degraded). After this, the kernel panic'd before completing the boot process with a "Page Fault in Supervisor Mode" error, and continued to panic this way until the DPT Array was COMPLETELY REBUILT OFFLINE (requiring me to boot into DOS and do it - doing the rebuild of that size RAID5 array takes more than an hour). After a complete rebuild, the DPT DRIVER showed the array sizes correctly. During this process, booting into DOS revealed the array to be fine, even while the array was degraded -- it also wasn't confused by degraded mode and showed correct partition information. I believe that the DPT DRIVER is not correctly sensing that the array is okay, even though it is in degraded mode, and incorrectly returns sector/MB values which panic the kernel. I don't recommend depending on the proper operation of this driver for your High-Availability needs. HISTORY I've used DPT in FreeBSD since last November, first with the hacked 2.2.2 driver. I upgraded to 2.2.6 to fix a MBUF leak that was crashing me about once per week. As 2.2.6, the MBUF leak disappeared and was replaced with a once every 2-3 day panic which it appeared was not going to get fixed by anyone (bidone: buffer not busy). So, I bit the bullet and upgraded recently to 3.0, which seemed to fix both of these prior panics only to reveal that the supposedly "high availability" software driver for my HA hardware is miserable during the most critical times. -Troy Cobb Circle Net, Inc. http://www.circle.net 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?509A2986E5C5D111B7DD0060082F32A402FABC>