Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 12 Dec 2004 22:03:36 -0800
From:      Joe Rhett <jrhett@meer.net>
To:        =?iso-8859-1?Q?S=F8ren?= Schmidt <sos@DeepCore.dk>, freebsd-stable@freebsd.org
Subject:   Re: drive failure during rebuild causes page fault
Message-ID:  <20041213060335.GD78120@meer.net>
In-Reply-To: <20041213054159.GC78120@meer.net>
References:  <20041213052628.GB78120@meer.net> <20041213054159.GC78120@meer.net>

next in thread | previous in thread | raw e-mail | index | archive | help
And here's where I found even more interesting stuff.  (again with the 
sil3114 controller)

If you detach a channel and then attach the channel, a new raid device gets
created.  And the removed drive shows up in the new array...

	# atacontrol create RAID0 ad6 ad8
	# atacontrol detach 4
	Dec 12 21:55:18 sandbox kernel: ad8: deleted from ar0 disk1
	Dec 12 21:55:18 sandbox kernel: ar0: WARNING - mirror lost
	Dec 12 21:55:18 sandbox kernel: ad8: WARNING - removed from configuration

	sandbox# atacontrol status 1
	atacontrol: ioctl(ATARAIDSTATUS): Device not configured

Okay, ar0 is broken, and raid array 1 doesn't exist.

	# atacontrol attach 4 
	Dec 12 21:55:57 sandbox kernel: ad8: 76319MB <ST380013AS/3.18> [155061/16/63] at ata4-master SATA150
	sandbox# atacontrol status 1
	ar1: ATA RAID1 subdisks: DOWN ad8 status: BROKEN

Hm? Where did this array come from?

Okay, so now someone will tell me that I'm doing things all out of order,
which I suspect.  But that leaves the obvious that "Others will do this"
and there is no documentation to suggest otherwise.

What about a command to show the current list of raid arrays?  either make 
'atacontrol status' return the status of all arrays in the system, or
make a new command that will list out which arrays are available.  I only
stumbled on this because I mistyped a number and then realized that I was
looking at the wrong thing (and the wrong thing should not exist!)

On Sun, Dec 12, 2004 at 09:42:00PM -0800, Joe Rhett wrote:
> And another, I can now confirm that it is fairly easy to kill 5.3-release
> during the rebuilding process.  The following steps will cause a kernel
> page fault consistently:
> 
> atacontrol create RAID0 ad6 ad10
> atacontrol detach 5
> 	log: ad10 deleted from ar0 disk1
> 	log: ad10 WARNING - removed from configuration
> atacontrol addspare 0 ad8
> 	log: ad8 inserted into ar0 disk1 as spare
> atacontrol rebuild 0
> atacontrol detach 4
> 	log: ad8 deleted from ar0 disk1
> 	log: ad8 WARNING - removed from configuration
> 
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x10
> ....
> current process = 1063 (rebuilding ar0 1%)
> trap number = 12
> panic: page fault
> 
> (tell me if you want or need anything I skipped above.  Got lazy cause I
> had to type it in by hand...)
> 
> -- 
> Joe Rhett
> Senior Geek
> Meer.net
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

-- 
Joe Rhett
Senior Geek
Meer.net



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041213060335.GD78120>