Most recent kernel where this bug did *NOT* occur: None Distribution: Debian 4.0 - Etch (final) Hardware Environment: HP/Compaq nc6000 laptop, Pentium M 1.6 GHz, Intel ICH4, ATI Radeon Mobility 9600, 512 MB RAM Software Environment: Debian-provided packages, self-compiled kernel Problem Description: If a kernel without CONFIG_MOUSE_PS2 enabled is used, the kernel won't detect my RAID1 array, but the hard drives it consits of are properly detected and the partition type reads "FD - Linux Raid Autodetect" as well. No /dev/md0 is created while booting the kernel. I built 2.6.21 with the same .config except for CONFIG_MOUSE_PS2 twice for testing purposes and discovered this weird thing. I'm going to attach the .config (without CONFIG_MOUSE_PS2), the dmesg of this kernel as well as the CONFIG_MOUSE_PS2-enabled kernels dmesg. Steps to reproduce: Compile kernel without CONFIG_MOUSE_PS2 and attach some hard drives that are part of a RAID array and see what happens...
Created attachment 11358 [details] .config of the kernel without CONFIG_MOUSE_PS2 that won't detect my RAID1
Created attachment 11359 [details] dmesg of working 2.6.21 with MOUSE_PS2 enabled
Created attachment 11360 [details] dmesg of malfunctioning 2.6.21 without MOUSE_PS2 enabled
Seems with a friend of mine I was able to figure out the reason for the problem: Without CONFIG_MOUSE_PS2 USB devices will be scanned after probing for MD devices, but with CONFIG_MOUSE_PS2 the kernel will scan for USB devices and then check for the MD devices. Because my RAID1 consists of two USB hard disks the RAID cannot be detected if the USB disks were not detected before ;) See the dmesgs, they prove it - sdb and sdc are my USB disks.
I replied to this by mail, but the mail->bugzilla gateway seems to be broken. I recommend the best approach is to not depend on in-kernel autodetect. Simply get an init script to run "mdadm" with a suitable config file. For completely proper handling of usb devices, you really want udev to be running "mdadm --assemble --incremental" on every hot-plug event, but you may not need that to get your system working. If you really want to see if this ordering can be fixed in the kernel you would need to change the "category" to point to usb / mass-storage. The problem isn't that md is auto-detecting any earlier. The problem is that USB is discovering the devices later. I would not be surprised if that will not be "Fixed".
I understand that this is not a serious bug, it's just a bit annoying if one is used to the in-kernel autodetection of RAID arrays. >If you really want to see if this ordering can be fixed in the kernel you >would need to change the "category" to point to usb / mass-storage. Where exactly would I try to change this category you're talking about? Thanks for the response anyway!
Modern raid setups use UUID for a reason