kern/43986: ataraid(4) doesn't seem to handle weird array configs very gracefully

["Greg A. Woods" <woods%planix.com@localhost>]

>Number:         43986
>Category:       kern
>Synopsis:       ataraid(4) doesn't seem to handle weird array configs very 
>gracefully
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 19 19:45:00 +0000 2010
>Originator:     Greg A. Woods
>Release:        NetBSD 4.0_STABLE 2010/10/15
>Organization:
Planix, Inc.; Toronto, Ontario; Canada
>Environment:
System: NetBSD historically 4.0_STABLE NetBSD 4.0_STABLE (GENERIC.MP) #1: Fri 
Oct 15 13:14:43 EDT 2010  
woods@once:/rest/build/woods/once/netbsd-4-i386-i386-ppro-obj/rest/work/woods/m-NetBSD-4/sys/arch/i386/compile/GENERIC.MP
 i386
Architecture: i386
Machine: i386
>Description:

        ataraid(4) doesn't seem to handle weird array configs very gracefully:

wd1 at atabus2 drive 0: <WDC WD2000JD-00HBB0>
wd1: drive supports 16-sector PIO transfers, LBA48 addressing
wd1: 186 GB, 387621 cyl, 16 head, 63 sec, 512 bytes/sect x 390721968 sectors
rnd: wd1 attached as an entropy source (collecting)
wd1: 32-bit data port
wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd1(piixide1:0:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
MAGIC == 0x00
wd2 at atabus3 drive 0: <WDC WD2000JD-00HBB0>
wd2: drive supports 16-sector PIO transfers, LBA48 addressing
wd2: 186 GB, 387621 cyl, 16 head, 63 sec, 512 bytes/sect x 390721968 sectors
rnd: wd2 attached as an entropy source (collecting)
wd2: 32-bit data port
wd2: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd2(piixide1:1:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
ataraid0: found 1 RAID volume
ld0 at ataraid0 vendtype 1 unit 0: Adaptec ATA RAID-1 array
uvm_fault(0xc0ab2c40, 0, 1) -> 0xe
kernel: supervisor trap page fault, code=0
Stopped in pid 0.1 (swapper) at netbsd:strncmp+0x23:    movzbl  0(%ebx),%eax
db{0}> trace
strncmp(c095397a,1c,6,282,c0a9564c) at netbsd:strncmp+0x23
devsw_name2blk(1c,0,0,0,0) at netbsd:devsw_name2blk+0x7e
ld_ataraid_attach(c3d9c940,c3dede00,c3da0600,c37d4000,c37f4000) at netbsd:ld_ata
raid_attach+0x1a8
config_attach_loc(c3d9c940,c0a0bb40,c0b96b54,c3da0600,c053c470) at netbsd:config
_attach_loc+0x3b0
ataraid_attach(0,c3d9c940,0,c04547fd,c095304c) at netbsd:ataraid_attach+0x87
config_attach_pseudo(c0a20e28,c0a20e00,c09c4c6c,241,7) at netbsd:config_attach_p
seudo+0x213
ata_raid_finalize(0,c0a1cfe0,0,20,20) at netbsd:ata_raid_finalize+0x4d
config_finalize(c0ab4114,20,c0967934,0,0) at netbsd:config_finalize+0x29
main(fbff,c01002d2,0,0,0) at netbsd:main+0x297
db{0}> 


>How-To-Repeat:

        1. set up a RAID-1 mirror in the hardware RAID controller config
        2. disconnect one drive
        3. delete the array
        4. connect the drive
        5. boot

        i.e. I think the problem was the disconnected drive was
        identified as being an array member and so the array
        re-appeared, but the second drive was in JBOD mode because it
        had been the only one connected when the array was initially
        deleted.

>Fix: