Date: Tue, 26 Jul 2005 13:30:26 +0200 From: Frode Nordahl <frode@nordahl.net> To: freebsd-current@freebsd.org Cc: sos@deepcore.dk Subject: Re: 6.0-BETA1: ATA RAID rebuild not working Message-ID: <3393C657-47A5-43FB-87B7-04555A41A1B5@nordahl.net> In-Reply-To: <81AE004D-82DD-4791-9C5F-64AF7B47E8E1@nordahl.net> References: <81AE004D-82DD-4791-9C5F-64AF7B47E8E1@nordahl.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25. jul. 2005, at 21.19, Frode Nordahl wrote: > Hello, > > I am having trouble rebuilding my ATA / SATA RAIDs with 6.0-BETA1. > > I have tried it on: > Intel SCB2 with onboard Promise PDC20267 UDMA100 controller > Intel 875WP3 with onboard ICH5 SATA150 controller > (Using PseudoRAID, not Intel MatrixRAID...) > > # atacontrol status ar0 > ar0: ATA RAID1 subdisks: DOWN ad6 status: DEGRADED > > # atacontrol addspare ar0 ad4 > ad4: inserted into ar0 disk0 as spare > > # atacontrol rebuild ar0 > > # atacontrol status ar0 > ar0: ATA RAID1 subdisks: ad4 ad6 status: REBUILDING 0% completed > > And then it just sits at 0% forever. I started a rebuild process on > the Promise this friday, and it is still at 0%. > > During my testing I noticed that when running atacontrol rebuild, a > dd process shows up. What is it for? > > root 546 0.0 0.3 3240 2760 p0- DNL Fri01PM 0:00.01 /bin/ > dd if=/dev/ar0 of=/dev/null bs=1m > > (note, it has run since friday) > > Tracing this process show the following: > sched_switch(c3885300,0,1) at sched_switch+0x177 > mi_switch(1,0) at mi_switch+0x270 > sleepq_switch(d7540f08,ececabc4,c0637469,d7540f08,0) at > sleepq_switch+0xe0 > sleepq_wait(d7540f08,0,0,c085c10e,e52) at sleepq_wait+0x30 > bwait(d7540f08,4c,c085429d) at bwait+0x47 > physio(c381be00,ececacbc,0,100000,c381be00) at physio+0x1db > devfs_read_f(c3859000,ececacbc,c3ae7780,0,c3885300) at devfs_read_f > +0x87 > dofileread(c3885300,4,c3859000,ececacbc,ffffffff) at dofileread+0x85 > kern_readv(c3885300,4,ececacbc,804f000,100000) at kern_readv+0x36 > read(c3885300,ececad04,3,1,246) at read+0x45 > syscall(3b,3b,3b,2104,bfbfed40) at syscall+0x22f > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (3, FreeBSD ELF32, read), eip = 0x280b9727, esp = > 0xbfbfec8c, ebp = 0xbfbfecd8 --- > > db> show locks > exclusive sleep mutex Giant r = 0 (0xc091dba0) locked @ /usr/src/ > sys/kern/kern_intr.c:544 > I did some detective work to try and narrow down when this stopped working: 5.3-RELEASE OK 5.3-RELEASE w/atamk3n OK* 5.4-RELEASE OK 5.4-RELEASE w/atamk3n NOT OK *) The dd starts and finishes, but status stays at 0%, and the RAID is never marked as clean So there are two seperate problems here, but I guess it's safe to say that something outside the ATA code changed to make rebuild not even start in 5.4-RELEASE and beyond. There seems to be a general problem with rebuild in atamk3n though. Frode Nordahl frode@nordahl.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3393C657-47A5-43FB-87B7-04555A41A1B5>